Method and apparatus for wireless communication in a mesh network with trackable randomized schedule

ABSTRACT

A method and apparatus for communication in a wireless sensor network. In one embodiment, one or more routers in a network may be available for communication with one or more star nodes at a randomized time and/or frequency. A connectivity assessment, which may be performed at several different frequencies and/or times, may be performed to evaluate the quality of communications between devices in the network. Primary and secondary communication relationships may be formed between devices to provide for system redundancy. One or more proxies may be maintained where each proxy includes a status of one or more devices in the network, e.g., one or more star nodes or routers. Proxies may be used to handle information requests and/or status change requests, e.g., a proxy may be requested to change a communication relationship between devices in the network and may generate command signals to cause the corresponding devices to make the change.

This application claims the benefit of U.S. provisional application60/557,026, filed Mar. 26, 2004, U.S. provisional application60/487,898, filed Jul. 17, 2003, and U.S. provisional application60/448,491, filed Jul. 17, 2003. This application is a continuation ofU.S. application Ser. No. 10/836,103, filed Apr. 30, 2004. U.S.applications 60/557,026; 60/487,898; 60/448,491 and Ser. No. 10/836,103are hereby incorporated by reference in their entirety.

BACKGROUND OF INVENTION

1. Field of Invention

This invention relates to wireless communication networks in whichwireless communication devices are active and send wireless informationto each other and/or a host computer.

2. Description of Related Art

As advances in technology enable the development of ever-smaller sensorsand actuators, capable of detecting events such as temperature change,movement, and touch, there has been increasing interest in creatingself-configuring wireless networks of these sensors and actuators,together with additional communication devices and software. Suchnetworks, typically known as Wireless Sensor Networks (WSNs), have avariety of potential applications. For example, WSNs may be used todetect soil moisture levels in plant nurseries, resulting in theautomated activation of fans (when the environment is too hot) orsprinklers (when soil is too dry). WSNs may be used to log unauthorizedhandling of sensitive or expensive items such as computer equipment orartwork, or to track vehicles in a large parking lot, or for a widevariety of other applications.

As WSNs emerge from the research laboratory and become commerciallyviable, a question arises: What might the topology and communicationsprocesses of such networks look like? Various aspects of the inventiondescribed below relate to the configuration and operation of such WSNs.

SUMMARY OF INVENTION

In one aspect of the invention, a wireless sensor network includes aplurality of Star nodes constructed and arranged to transmit and receivewireless signals. At least one of the Star nodes is associated with atleast one corresponding sensor device and is constructed and arranged totransmit a wireless signal including information from the correspondingsensor device. A plurality of Routers is each constructed and arrangedto transmit and receive wireless signals for communication with at leastone Star node and is constructed and arranged to transmit and receivewireless signals for communication with at least one other device in thenetwork. Each of the plurality of Star nodes communicates with at leastone Router using multiple frequencies. The Routers are each availablefor communication with at least one Star node for a period that beginsat a randomized time or at a randomized frequency.

In one aspect of the invention, a wireless sensor network includes aplurality of Star nodes constructed and arranged to transmit and receivewireless signals. At least one of the Star nodes is associated with atleast one corresponding sensor device and is constructed and arranged totransmit a wireless signal including information from the correspondingsensor device. A plurality of Routers is each constructed and arrangedto transmit and receive wireless signals for communication with at leastone Star node and is constructed and arranged to transmit and receivewireless signals for communication with at least one other device in thenetwork. At least one Star node or at least one Router performs aconnectivity assessment that indicates a measure of a quality ofwireless communication between the at least one Star node or the atleast one Router and at least one other device in the network. Theconnectivity assessment is used to determine a communicationrelationship between the at least one Star node or at least one Routerand the at least one other device.

In one aspect of the invention, a wireless sensor network includes aplurality of Star nodes constructed and arranged to transmit and receivewireless signals. At least one of the Star nodes is associated with atleast one corresponding sensor device and is constructed and arranged totransmit a wireless signal including information from the correspondingsensor device. A plurality of Routers is each constructed and arrangedto transmit and receive wireless signals for communication with at leastone Star node and is constructed and arranged to transmit and receivewireless signals for communication with at least one other device in thenetwork. A Host computer communicates with the plurality of Routers atleast in part via wireless signals. The Host computer includes a set ofsoftware proxies that include status information consistent with thecurrent status of the plurality of Star nodes and the plurality ofRouters.

Aspects of the invention also relate to a method for communication in awireless sensor network. In one embodiment, one or more routers in anetwork may be available for communication with one or more star nodesat a randomized time and/or a randomized frequency. In anotherembodiment, a connectivity assessment may be performed to evaluate thequality of communications between one or more star nodes, or one or morerouters, in the network, and at least one other device in the network.Based on the connectivity assessment, communication relationships may beformed. The connectivity assessment may be performed at severaldifferent frequencies and/or at different times. Primary and secondarycommunication relationships may be formed between devices in the networkto provide for system redundancy. In another embodiment, one or moreproxies may be maintained for a wireless sensor network where each proxyincludes or represents a status of one or more devices in the network,e.g., one or more star nodes or routers. Proxies may be used to handleinformation requests and/or status change requests for the network,e.g., a proxy may be requested to change a communication relationshipbetween devices in the network and may generate command signals to causethe corresponding devices to make the corresponding change.

These and other aspects of the invention will be obvious and/or apparentfrom the following description. Various aspects of the invention may beused alone or in any suitable combination.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the invention are described below with reference to thefollowing drawings in which like numerals reference like elements, andwherein:

FIG. 1 shows an example of a Wireless Sensor Network (WSN) in accordancewith the invention.

FIG. 2 shows an overview of a system configured according to theinvention.

FIG. 3 illustrates the process of a node joining a WSN.

FIG. 4 shows an example of a WSN with a simple hub-and-spokeconfiguration.

FIG. 5 shows an overview of the layered structure of a WSN according tothe invention.

FIG. 6 is a block diagram of a WSN node.

FIG. 7 illustrates the effect of changing frequency on a radioenvironment.

FIG. 8 illustrates transmission of Frame Beacons and Contention AccessPeriods at different frequencies over time.

FIG. 9 illustrates transmission of the FH Beacon on the previous channelusing a portion of Hop Sequence A as an example.

FIG. 10 illustrates a hybrid authentication/encryption scheme in a WSN.

FIG. 11 shows the uncertainty that may be accounted for by a node inforecasting Beacon timing.

FIG. 12 illustrates the chaining of Connectivity Assessments and the useof routing tables with probabilities.

FIG. 13 shows an embodiment of packet structure in a WSN.

FIG. 14 illustrates a send/retry strategy for messages from a node tothe Host in a WSN.

FIG. 15 illustrates a method for message forwarding without involvingthe Host.

FIG. 16 illustrates how a WSN may be restructured if a Router is lostvis-á-vis the network.

FIG. 17 illustrates the chaining of Connectivity Assessments and the useof routing tables with probabilities in a WSN with more than oneGateway.

FIG. 18 illustrates one embodiment of a WSN architecture.

FIG. 19 shows an overview of some elements that may be present in a WSN.

FIG. 20 shows an embodiment of a WSN controller.

FIG. 21 shows an embodiment of a proxy.

DETAILED DESCRIPTION

Aspects of the invention are described below with reference toillustrative embodiments. However, it should be understood that aspectsof the invention are not limited to those embodiments described below,but instead may be used in any suitable system or arrangement. As usedherein, “randomized” means a value or property that is determined basedon a random or pseudorandom process. Also, use of the language “at leastone of A or B” is intended to include/encompass A only, B only, and Aand B.

Aspects of the invention are described in relation to a WSN with astructure similar to that of a number of hub-and-spoke WLANs strungtogether into a mesh or hierarchical structure, as shown in theillustrative embodiment of FIG. 1.

The FIG. 1 system components may include:

-   -   Star nodes. Star nodes 1 may include small, battery-powered        wireless radio transceivers that may provide low-bandwidth        wireless connectivity for attached devices such as sensors        (e.g., temperature, chemical, airflow) and actuators (e.g.,        fans, LEDs, switches). Star nodes 1 may be specialized to        provide sensor connections for supporting specific applications.        Examples may include security nodes for object touch detection,        and environmental nodes for reporting temperature and humidity.    -   Routers. Routers 2 may be specialized nodes that self-organize        into a WSN backbone. Routers 2 repeat or route the data        transmitted on the WSN 100. They may transmit or relay messages        to another node on the network, including Star nodes 1, Routers        2, or Gateways 3. They may also be configured to support various        sensor connections. Routers 2 may also have parents; a Router's        parent may be either another Router 2 or a Gateway 3.    -   Gateways. Gateways 3 or Bridges may be mechanically similar to        Routers 2, except that, in place of re-transmitting messages,        they may provide an interface to a different physical or logical        network. Bridges are similar to Gateways 3. Bridges share a        common network layer with connected devices (such as Star nodes        1 and Routers 2) and may translate communications for a        different medium while preserving a network protocol. Gateways 3        may serve as portals to different types of networks, terminating        the WSN protocol and translating communications to a different        protocol appropriate for the new network. As used herein, the        term “Gateway” refers to a single device that acts as a        clearinghouse for WSN control functions, with the understanding        that some of these functions may actually be implemented in a        distributed fashion across a set of Gateways 3 and/or on other        devices such as a Host 4 computer or specialized network nodes.        Gateways 3 may be attached to a wired network such as Ethernet.        Different Gateway 3 products may be configured for alternative        networks such as Ethernet, WiFi, cellular, RS232, BACnet,        LonWorks, or even simply binary switch outputs.    -   Host. A Host 4 may operate on a Windows-based or other computer.        A Host 4 may include a secure database for maintaining        information such as encryption keys. A Host 4 may also include        Host Software, which may provide an interface to the WSN 100,        direct data to and from proxies (which may represent some or all        of the Routers 2 and/or Star nodes 1) into a database, and offer        GUI applications that may present data, allow actuation (if        applicable), and support network administration.

In this specification, “node” or “device” may refer to a Star node 1,Router 2, or other networked device. Within the system, Routers 2 andStar nodes 1 may have parent-child relationships, with Star nodes 1being children of one or more Router 2 parents. Each Star node 1 mayhave a primary parent Router 2 and, if possible, a secondary parentRouter 2 for redundancy. Gateways 3 may also act as parents. In thefollowing pages, we describe network architectures and protocolsdesigned for use in wireless sensor networks. In this discussion, wedescribe certain illustrative embodiments; however, these descriptionsare purely illustrative and are not intended to be limiting.

In discussing network architectures and protocols, we consider manyfacets of network structure and operation, including network formation,communication, system enhancements, network restructuring, and security.Before discussing these items in depth, we provide an overview ofseveral aspects of the invention, which are described, along withadditional features, in more detail subsequently.

The overview of several additional aspects of the invention is providedbelow with reference to the illustrative embodiment of FIG. 2. The FIG.2 embodiment is similar to that in FIG. 1, but includes several Gateways3 that may communicate with a Host 4 via an Ethernet link 50.

Frequency Agility

One of the aspects of the invention incorporated into the FIG. 2embodiment is support for frequency agility, or the ability of a WSN 100to support communication on multiple frequency channels. In one aspectof the invention, nodes may use two or more different frequency channelsin a sequence for communication, e.g., nodes may be enabled forcommunication at randomized frequencies and/or at randomized times.Channel usage may not necessarily be coordinated across the network;thus, each parent node may utilize a different sequence of channels,depending on such factors as conditions in the radio environment andinterference from other nearby wireless devices. For example, in FIG. 2,Router 2 a is utilizing channel Sequence A, while Router 2 d is usingSequence F and Router 2 c is using Sequence D. A Sequence may include orbe defined by a specific or randomized sequence of different frequenciesused for communication and/or a specific or randomized timing by whichthe different frequencies are used. This timing by which frequencies areused may define a start time when frequencies are used and/or a lengthof time that the frequencies are used. Child nodes may know whichSequence is being used by their parent node(s) so that the Child nodesmay predict when and on what channel their parents may be available forcommunication. Each node may also select preferred channels forcommunication with its parents.

This frequency agile approach may have several potential benefits. Forexample, frequency agility may help WSNs to overcome some of thedifficulties posed by network crosstalk, interference within thefrequency band being used, and multipath conditions. These benefits, aswell as more detail concerning some embodiments of frequency agile WSNs,are discussed subsequently.

Support for Multiple Gateways

In another aspect of the invention, a WSN 100 may provide support formultiple Gateways 3. In the example in FIG. 2, Gateways 3 a (X), 3 b(Y), and 3 c (Z) are each connected to a Host 4 via a common Ethernetbackbone 50. Arrows indicate the flow of data toward the Gateways 3 a-c.(Data may flow in both directions over all pathways, but in many WSNapplications the bulk of the data may flow toward a Gateway 3.) EachGateway 3 may have one or more child Routers 2. Some Routers 2 may havechildren, including other Routers 2 and Star nodes 1, and each Router 2and Star node 1 may have two parents (e.g., primary and secondaryparents). Star nodes 1 may also be children of Gateways 3.

The parent/child relationship may be used to determine the path by whichnodes communicate with a Gateway 3. For example, a Star node 1 maycommunicate with a Gateway 3 via a parent Router 2, which in turn maycommunicate with its parent Gateway 3. A node may communicate using oneor more pathways. For example, a Star node 1 may use a primary path tocommunicate with a Gateway 3, e.g., via a first parent Router 2 thatcommunicates directly with the Gateway 3. The Star node 1 mayalternately communicate with the Gateway 3 via a secondary path, e.g., asecond parent Router 2 that communicates with the Gateway 3.Communication paths may be structured in any suitable way, such ashaving a Star node 1 communicate with a Host 4 via one or more pathwaysthat each include one or more different Star nodes 1 and/or one or moreRouters 2 and/or one or more Gateways 3. A node may use a primary pathand switch to a secondary path when communication via the primary pathis impossible or otherwise impeded. This redundancy may help ensure thatcommunication for each node is maintained.

In a multi-Gateway 3 configuration, a device's secondary path may leadto a different Gateway 3 than the device's primary path. For example, inFIG. 2, Router 2 h (H) has a primary path to Gateway 3 b (Y) and asecondary path to Gateway 3 c (Z). This type of system may be configuredso that there is no single point of failure in routing; if a Router 2 ora Gateway 3 fails, there may be another path by which a device cantransmit messages. A multi-Gateway configuration also has the advantagethat the number of hops to a Gateway 3 may be reduced when Gateways 3are interspersed among Routers 2.

Connectivity Assessments

In another aspect of the invention, a node may perform one or moreconnectivity assessments and choose one or more parents. To assessconnectivity, a node may listen for messages from nearby Routers 2, sothat the node may determine which prospective parents are within range.A node may accomplish this by choosing a frequency channel and remainingon that channel for some period of time, determining which Routers 2 thenode can hear, and assessing connectivity to each of those Routers 2.(As discussed in more detail below, Gateways 3 may also accept children.In most of this disclosure, devices that emit beacons and/or supportchildren are called Routers 2, with the understanding that less numerousGateways 3 also emit beacons and support children. Such use of the word“Router” is not intended to exclude Gateways 3.)

More accurate connectivity assessments may be obtained if the nodesamples more than one frequency channel. Due to multipath conditions,network crosstalk, and other factors, for example, a node may measureadequate connectivity to Router A on channel 15, but strong connectivityto Routers B and C on channel 23. By assessing connectivity on multiplechannels, the node may take full advantage of a WSN's frequency agility,if provided along with a connectivity assessment feature in a network.

Thus, to perform connectivity assessments, a node may listen formessages from Routers 2 on one channel, collect connectivityinformation, switch to a new channel, collect addition information(potentially from different Routers 2), and so on. Based on connectivityassessments at multiple frequencies, the node may be able to select itsparent Routers 2 (or provide information to the Host 4 for selection)from among the Routers 2 it can hear best at different frequencies,rather than restricting its choices only to those Routers 2 that can beheard at a particular frequency. Such assessments may be similarlyuseful in selecting the node's preferred communication channels.

Virtual Proxy Devices

In another aspect of the invention, a WSN 100 may support a set ofsoftware objects that may be accessible at the Host 4 via TCP/IP orother suitable protocol. These software objects, or proxies, may providean abstraction of the network for application programs, whereby each WSNdevice may be represented as a software object. Examples of proxyobjects may include nodes, sensors, and actuators. The proxies mayhandle the details of keeping the virtual devices on the Host 4consistent with the physical devices on the network and mayautomatically track time-variant network information such as sensorstate, device connectivity, and network configuration.

The proxies may be used, for example, to pass information to and fromspecific applications. Requests for data by application programs may bedirected to the proxies. Such requests may be handled with recent datathat is already available to a proxy. Alternatively, new data may besent to the proxy prior to the proxy's response to the request for data.Requests to change network devices may be similarly directed to theproxies; the proxies in turn may handle the details of changing thenetwork in reaction to changes in the software objects.

Joining the Network

In another aspect of the invention, a node may join a WSN 100 by asimple procedure, as shown, for example, in FIG. 3. When a node firstawakens (S1), it may need to acquire the time base of the system bylistening for messages (called “Beacons”) from Routers 2 that havealready joined the network (S2). Once it has acquired the time base ofthe system (S3), the node may communicate with at least the Router(s) 2from which it heard the Beacons.

Before it is allowed to join the network, the node may need to passthrough some optional security checks (S4), such as for authentication.Network encryption keys may be securely provided to the node as part ofthe authentication process.

Once a node has associated with the network (S5), it may acquire itsparents. To do this, the node may listen for Beacons, performconnectivity assessments (S6), and choose its parents (S7).Alternatively, it may report connectivity data to a Host 4 that choosesparents on behalf of the node.

At first, a device may simply join the network as a Generic node. Once anode has joined the network, a distinction may be made between Routers 2and Star nodes 1 (S8). If the node is a Star node 1, then it may reportits feature set (S9) and begin its work (S10) (for example, collectingand reporting sensor data if it is a sensor-attached Star node 1). Ifthe node is a Router 2, it may report its configuration (S11) androuting information to its parents, become part of the network backbone,and begin transmitting Beacons (S12).

Having introduced several, but not necessarily all, aspects of theinvention, a more detailed discussion of illustrative embodiments inaccordance with aspects of the invention is provided below.

Basic Functions in Wireless Sensor Networks

In this specification, some WSN coordination functions may be handled bya Gateway 3 and software at the Host 4. Gateway 3/Host 4 functions mayinclude starting sessions, acting as a clearinghouse for device IDs, andother functions (some of which are described in later sections). Gateway3/Host 4 functions may be provided by a single device or by multipledevices, such as a primary Gateway 3, a secondary Gateway 3 forredundancy, and a computer running application software at the Host 4.

In one embodiment, WSN coordination functions may be handled by aservice running under Microsoft Windows on a Host 4 PC. The primary andsecondary Gateways 3 may be connected to the Host 4 PC by an RS232connection. It is not necessary that the Host 4 be a PC running Windowsand connected to a network. For example, a Host 4 may be a Windowsworkstation or an embedded device running Windows Embedded, Windows CE,or Linux. A specially programmed Gateway 3 may fulfill the Host 4function in small networks. Multiple Gateways 3 may fulfill Host 4functions in a distributed fashion on larger networks.

TCP/IP packets may be used to communicate between services. For example,a WSN coordination service may send data to a GUI. The services need notbe on the same machine. For example, the WSN coordination service mayreside on one machine, while the GUI may reside on another.

To maintain reliability, packets sent from a given node may requireacknowledgement back from the receiving node. If the acknowledgement isnot received, the sending node may re-transmit its message. This helpsto ensure that data will not be lost if there is a problem with networkcommunication.

During normal operation, nodes may periodically send “heartbeats” totheir primary and secondary parents. Heartbeats may be used to pollparents for pending store-and-forward messages. Heartbeats may alsoindicate that no one has tampered with a node. Generally, heartbeats andother functions described herein help maintain WSN health on adecentralized basis.

WSNs and IEEE 802.15.4

IEEE 802.15.4 defines a radio networking protocol that is simple,inexpensive, and low power. It is intended to operate in unlicensed,international frequency bands. Targeted applications include wirelesssensors, interactive toys, smart badges, remote controls, and homeautomation.

Aspects of the IEEE 802.15.4 specification may be incorporated into aWSN in embodiments of the invention, albeit with some modification asdescribed below. For example, IEEE 802.15.4 provides Medium Access Layer(MAC) primitives for Routers 2 and Star nodes 1 to communicate, but thestandard does not provide a way for Star nodes 1 to communicate withother Star nodes 1, nor does it specify how Routers 2 configurethemselves into a network. In this specification, Routers 2 roughlycorrespond to IEEE “full-function devices” (FFDs), while Star nodes 1correspond to “reduced-function devices” (RFDs).

FIG. 4 shows an example of a WSN 100 with a simple hub-and-spokeconfiguration. IEEE 802.15.4 is designed for this simple sort ofconfiguration, with a single parent and a set of children within theparent's sphere of influence, where parents may be Gateways 3 or Routers2 and children may be Star nodes 1 or other Routers 2. In thisspecification, we do not intend to limit our discussion to WSNs with asingle parent and its children; the concepts described herein may referto expanded WSNs with multiple Gateways 3 and Routers 2 such as theexample pictured in FIG. 2.

The IEEE 802.15.4 standard includes a set of protocols that are designedto allow the Star nodes 1 to sleep most of the time, allowing them to bebattery powered. The Routers 2, by contrast, are intended to be awakemost of the time, available to respond instantly if a child node needsimmediate service. Thus, a Star node 1 may detect an alarm condition andimmediately send a message to a nearby Router 2. To quote from thestandard, “The PAN coordinator [i.e., Router 2] may be mains powered,while the devices [i.e., Star nodes 1] will most likely be batterypowered.” This specification builds upon the IEEE 802.15.4 specificationto support Routers 2 operating in a power-saving mode in which they wakeup frequently (such as twice per second) and for brief periods of time.

As shown in FIG. 5, a WSN software stack 203 may be built on the base ofthe PHY 201 and MAC 202 layers of the IEEE 802.15.4 standard, extendingit with a robust network layer 204. In an alternative embodiment, the802.15.4 Direct Sequence Spread Spectrum (DSSS) physical layer 201 maybe replaced with a Frequency Shift Keyed (FSK) frequency hopper in the902-928 MHz. Alternative radios operating in different frequency bandsare also an option.

In accordance with aspects of the invention, network configuration in aWSN 100 may be ad hoc, allowing Star nodes 1 (which may support sensorsor actuators) to enter or leave the network regularly, as well aseliminating the requirement that Routers 2 remain permanentlystationary. Communication between parents and their children may bebuilt upon the MAC layer defined in the IEEE 802.15.4 standard. A NETlayer, built upon the MAC layer, may handle communication among Gateways3 and Routers 2.

In one embodiment, devices used in a WSN 100 may use an IEEE802.15.4-compliant radio such as the Chipcon CC2420, combined with aprocessor such as the Texas Instruments MSP430 processor. The MSP430processor is a suitable choice due to its power saving capabilities,especially its ability to run at low voltage. The Chipcon CC2420 has thephysical layer built-in, as well as parts of the MAC, such as AES-128encryption, CRC check, and MAC-level acknowledgements. The rest of theMAC and the network layer may be implemented using a separatemicroprocessor.

In another embodiment shown in FIG. 6, devices used in a WSN 100 may usea narrowband radio such as the Chipcon CC1000 radio running in the902-926 MHz unlicensed band, combined with a processor such as the TexasInstruments MSP430 processor. Embedded software may be written in the Cprogramming language. CC1000 radios have limited output power, and apower amplifier (that may be included in a custom radio circuit) mayprovide additional link margin. A plastic housing 300 may surround thenode electronics, which may include LEDs 301; a piezobuzzer 302; anRS232 interface 303; a radio 306; an amplifier 307 (if needed), whichmay include an RF amplifier 308, a transmit/receive switch 309, and aband pass filter 310; an antenna 311; a processor 304; specializedsensors such as a temperature/humidity sensor 305 and a touch sensor312, which may incorporate an RS232 interface 313, a processor 314,touch sensor interfaces 315, and screw terminals 316; and auxiliaryinterfaces, which may include an auxiliary sensor 317, an auxiliary I/Ointerface 318, and screw terminals 319.

The PHY and MAC layers used in illustrative embodiments of the inventionmay differ from the 802.15.4 PHY and MAC layers, such as to support theuse of frequency hopping or adaptive frequency agility. Nonetheless, itis preferable to generally follow the structure of the IEEE 802.15.4standard to retain compatibility with a range of highly integrated chipsexpected to be available from multiple vendors. Aspects of the inventionare designed to provide the advantages, for example, of frequencyagility within the pre-defined IEEE paradigm and constraints.

IEEE 802.15.4 does not address NET and APP layers, so a WSN 100 may addits own NET and APP layers. WSN devices may also include an interfacefor sensors and/or actuators.

Although WSNs in accordance with various aspects of the invention mayborrow some structure and terminology from 802.15.4, there are somefundamental differences. For example:

-   -   Routers 2 may be strung together into a network providing        connectivity among Star Nodes 1, Routers 2, and Gateways 3, for        example, as illustrated in FIG. 2.    -   In 802.15.4, Nodes start out as orphans and then associate with        one and only one Coordinator. In the structure described in this        specification, each Node may associate with multiple parents,        such as a primary and a secondary Router 2 for redundancy.

One embodiment herein utilizes FSK modulation and 900 MHz radios withfrequency hopping, and another embodiment uses IEEE 802.15.4 radios at2.4 GHz with DSSS communication and QPSK modulation. The techniquesdescribed may be similarly applied to either type of system. Themodulation may simply be used as a way to carry data, and thus thetechniques described herein may be applicable regardless of the type ofmodulation used. Similarly, although 802.15.4 may use different (andfewer) channels than a narrow band radio, the same techniques may beapplied in roughly the same manner in both 802.15.4 and the proprietaryradios. Thus, although many of our points below are illustrated usingIEEE and FSK radios as example implementations, this is not intended tobe limiting.

Frequency Agility Implementation

Radio communication systems with frequency agility (i.e., using multiplefrequency channels) may have several benefits over systems using asingle channel for communication. For example, if nearby devices areoperating in a cross-interfering frequency band, a system with frequencyagility may retry communicating on a different and hopefullynon-interfering channel. Similarly, if multipath problems affectcommunication, localized multipath conditions are likely to change whenthe system shifts to a different frequency.

The effect of changing frequency on the radio environment is illustratedin FIGS. 7A-7C, which depict signal strength using a narrowband radiofor transmission, and a spectrum analyzer measuring received signalstrength at six-inch increments shown on the grid. Data was taken in atypical indoor office environment, in the same location but at 918 MHzfor FIG. 7A, 922 MHz for FIG. 7B, and 926 MHz for FIG. 7C. Light shadesindicate strong signals, while darker shades indicate nulls, in 5 dBmincrements. As FIGS. 7A-7C show, dramatic differences in signal strengthcan result from slight changes in the signal environment, such as movingtransmitters or receivers by just a few inches. The experiments alsoshow that changing the frequency around a relatively narrow band helps;a frequency change of even a few MHz can result in a dramaticallydifferent pattern of nulls. Frequency agility thus makes a systemtolerant to nulls. With frequency agility, nulls will occur but arelikely to evaporate if the sender retries on an alternative frequency.

In accordance with one aspect of the invention, frequency agility may beespecially useful in WSNs. In a redundant mesh network, it may not beunusual for ten or more Routers 2 and potentially hundreds of Star nodes1 to be within range of each other. If all nodes were operating at thesame time and in the same frequency channel, such sharing of a channelmight result in substantial network crosstalk. Three strategies may beused to overcome such an issue. First, the randomized nature of theRouter's wake cycles makes it relatively unlikely that two given Routers2 will be operating at the same time, unless their wake cycles areexplicitly synchronized in a parent/child relationship. Second, if twounrelated Routers 2 happen to be operating at the same time, therandomized use of available radio channels makes it unlikely that theywill be able to hear each other. Third, in the relatively infrequentevent that two Routers 2 happen to be operating in the same frequencyand at the same time, the CSMA-CA scheme in IEEE 802.15.4 enables theRouters 2 to share the channel. The result is that each Router 2 and itschildren can operate as envisioned in the IEEE specification, relativelyundisturbed by nearby Routers 2 and their children. Thus, using aspectsof the invention, the hub-and-spoke clusters envisioned by IEEE may bestrung together into a scalable and extensive mesh network.

Two types of frequency agility approaches are discussed below, adaptivefrequency agility and frequency hopping, which may be incorporated intoembodiments of the invention. Other frequency agility approaches arepossible, as those discussed below are not intended to limit aspects ofthe invention.

Adaptive Frequency Agility

In one embodiment, the WSN architecture may utilize adaptive frequencyagility (AFA). In the IEEE 802.15.4 standard, sixteen DSSS (directsequence spread spectrum) frequency channels are available in the2400-2483 MHz band for communication between networked devices. Thechannels operate at 2 megachips and 250 kbps, spaced at intervals of 5MHz. A system installer may configure the system to use from one tosixteen operating channels, including “control channels.”

Control channels are the channels that an unassociated node checksbefore joining the network. One, two, three, or more control channelsmay be designated for this purpose as an installation parameter. The useof more than one control channel allows a node to detect nearby Routers2 even if there is a problem on one channel due to multipath or radiointerference. Generally, channels 15 (2425 MHz) and 20 (2450 MHz) aregood choices for control channels, as they lie midway between thecommonly used 802.11b channels 1 (2412 MHz), 6 (2437 MHz), and 11 (2462MHz).

In one embodiment, a WSN 100 may utilize adaptive frequency agility(AFA) among up to 16 available channels (11-26) in apseudorandomsequence. Supported channel sequences may be written into the memory ofthe nodes at manufacture, to be selected when the system is operating.Alternatively, a sequence of 16 channels may be expressed in one-halfbyte per channel, and thus specified in 8 bytes that can be transmittedwirelessly to and from a Router 2. Supported sequences might include:

Sequence A

-   -   26,19,12,18,25,20,14,24,16,11,21,13,23,17,22,15

Sequence B

-   -   15,22,17,23,13,21,11,16,24,14,20,25,18,12,19,26

Sequence C

-   -   20,25,19,26,16,21,11,15,24,14,23,13,18,22,17,12

Sequence D

-   -   12,17,22,18,13,23,14,24,15,11,21,16,26,19,25,20

Sequence E

-   -   25,11,17,22,15,20,24,14,23,16,21,13,19,26,18,12

Sequence F

-   -   12,18,26,19,13,21,16,23,14,24,20,15,22,17,11,25

Through software at the Host 4, a user may select which pseudorandomsequence is used. Alternatively, sequences may be randomly assigned orselected for or by the Routers 2, or randomly generated by or on behalfof each Router 2.

Each Router 2 may choose a set of channels for its communications basedon a combination of user configuration and adaptive algorithms. Some ofthe ways that Routers 2 may adapt are described in more detail below.

In one embodiment of an AFA system, Routers 2 may periodically transmitmessages called Frame Beacons. These Frame Beacons may be very short, onthe order of two milliseconds each. At two milliseconds, one FrameBeacon per second uses about 0.2% of the channel bandwidth. In oneembodiment, Frame Beacons may serve several purposes:

-   -   Frame Beacons may start a “contention access period,” which is a        period during which Child nodes may initiate communications with        a Parent (Router 2 or Gateway 3) and vice versa. Frame Beacons        may signal the availability of the Parent for communication on a        particular frequency channel for a period of time.    -   Frame Beacons may multicast a synchronized time base to their        child nodes.    -   Frame Beacons may include scheduling information for future        Frame Beacons so that other nodes can predict the availability        of a given Router 2, thus synchronizing their sleep periods with        the Router's scheduled operation.

A Frame Beacon may contain one or more of the following:

-   -   PHY Header    -   MAC Header    -   WSNID    -   Session ID (that may be used to distinguish between network        communications sessions, such as when a network times out and        reforms)    -   Router ID    -   Current time    -   Last time network parameters changed    -   Current offset into pseudonoise sequence table (that may be used        to calculate dither)    -   Current offset into AFA Sequence table (that may be used to        determine the currently active communications channel)    -   List of Children with store-and-forward message in the queue (as        described subsequently)

To provide a full context for the incremental status information in theFrame Beacon, children may query a Router 2 separately to learn the hopsequence, Frame Beacon timing parameters, and other information that isspecific to a network session and/or Router 2 and does not normally varyduring a session.

Referring to FIG. 8, a Router 2 may transmit a Frame Beacon 401 to starta contention access period (CAP) 402 on a particular frequency channel.The CAP 402 is a time window when the Router 2 is available tocommunicate with its Children on a particular channel. The CAP 402 maybe relatively long, on the order of 0.1 to 0.5 second. The Router'sChildren may contend for the channel using CSMA-CA (carrier sensemultiple access with collision avoidance). Various types of channelaccess mechanisms may be used, depending on the network configuration.Unslotted and/or slotted channel access may be employed as specified inIEEE 802.15.4.

Networks may use an unslotted CSMA-CA channel access mechanism. Eachtime a device wishes to transmit data frames or MAC commands, it maywait for a random period. If the channel is found to be idle, followingthe random backoff, it may transmit its data. If the channel is found tobe busy, following the random backoff, the device may wait for anotherrandom period before trying to access the channel again. Acknowledgmentframes may be sent with very short latencies and without using a CSMA-CAmechanism.

Alternatively, networks may use a slotted CSMA-CA channel accessmechanism, where the backoff slots are aligned with (for example) thestart of Beacon transmission. Each time a device wishes to transmit dataframes during the CAP 402, it may locate the boundary of the nextbackoff slot and then may wait for a random number of backoff slots. Ifthe channel is busy, then following this random backoff the device maywait for another random number of backoff slots before trying to accessthe channel again. If the channel is idle, the device may begintransmitting on the next available backoff slot boundary. Acknowledgmentand Beacon frames may be sent with very short latencies and withoutusing a CSMA-CA mechanism.

A Router 2 may select the timing of Frame Beacons 401, as well as thechannel on which they are transmitted at a given time, through acombination of user configuration and adaptive algorithmns. The timingand channel of Frame Beacons 401 may be regular and pseudorandom. Forexample, a Router 2 may be set to send a Beacon every 0.50 seconds, witha randomized dither of plus or minus 0.10 seconds. The randomized dithermay be calculated using a linear congruential generator of the form inEquation 1:R _(n+1)=(a·R _(n) +b)mod m   (1)

The values a (the multiplier), b (the increment), and m (the modulus)are pre-selected constants. The choice of constants is well studied inthe computer science literature.

Transmission of the value R_(n) with each Frame Beacon 401 may allow anode to “lock on” to the Router's pseudorandom number sequence. This inturn may be used to forecast the timing of future transmissions, thusallowing the node to wake up and sample the channel at the time atransmission is expected.

Alternatively, and for less computational complexity, the dither may bederived from a lookup table that is shared across the network.

These two techniques may be combined, with a linear congruentialgenerator used to generate a table of a sequence of x pseudorandomnumbers. A device wishing to duplicate the table and synchronize withthe Router 2 may need the pseudorandom seed used to generate the table,the table length, and the current offset into the table.

For example, a node may use a seed in a linear congruential generator togenerate a table of 32 pseudorandom numbers. Each of the table entriesmay be taken as a dither amount. For example the low-order 7 bits may beused to set the dither in milliseconds, resulting in a dither of ±128milliseconds (approximately±0.1 seconds). Thus a Router 2 may send aFrame Beacon 401 every 0.5 sec±a randomized dither from the table. Inthis example, the true time to cycle through a table of 32 entries wouldbe 16 seconds±(sum of all 32 randomized dithers). In this example, if anode is asleep for 90 seconds, the node may synchronize with its parentRouter 2 thusly. First, the integer portion of 90 seconds divided by (16seconds±(sum of 32 randomized dithers)) will calculate the amount oftime to return to exactly the current position in the table. Theremainder may be used to calculate the Router's scheduled wakeup timethat most closely approximates the child's desired 90 second sleepcycle.

Using one of the above methods and a synchronized time base, a node maysynchronize itself to its Router's schedule of Frame Beacons 401. Thus,a child node may precisely time its wake cycles to coincide with itsparent's operation.

As part of a configuration process, a Router 2 may be instructed to senda Frame Beacon 401 once every y seconds (e.g., once every 0.5 seconds±arandomized dither). The system may then select one of several availabletable-driven sequences of channels. Also as part of the configurationprocess, the Router 2 may be instructed to send a Frame Beacon 401 oneach control channel at least once every z seconds (e.g., once everythree seconds), inserting extra unscheduled beacons if necessary toachieve this criterion. This may enable a new device to scan first onechannel for z seconds and then another channel for z seconds to join thenetwork.

It is not strictly necessary for every CAP 402 to begin with thetransmission of a Frame Beacon 401. For example, every third CAP 402 maystart with a Frame Beacon 401, with the other frames occurring on aknown schedule but without beacons. A node that has been asleep for along time may need to hear a Frame Beacon 401 to synchronize its time toits parent's, but once the time is synchronized it may participate inCAPs 402 that are not initiated with Frame Beacons 401. This strategycan save both energy and bandwidth.

The timing and/or duration of a Router's CAPs may be adaptive. Forexample, if a disproportionate amount of a Router's traffic isconcentrated in certain channels (presumably due to poor connectivity onother channels), the Router 2 may make itself available more often orfor a longer period of time on those channels, for example asillustrated in FIG. 8. Conversely, if a Router 2 detects no networktraffic for the first few milliseconds or slots of a CAP 402 on aparticular channel, the Router 2 may simply go into low-power mode untilthe scheduled time for its next CAP 402. Similarly, if a frequencychannel is very active, the Router 2 may remain in operation on thatchannel until it is time for the next CAP 402 on a different channel. Ifcertain channels become overused, the Router 2 may reconfigure itself tofor more frequent CAPs 402 on those channels, and/or instruct itschildren to favor alternative channels.

Channels and CAPs 402 in an AFA system are not necessarily coordinatedacross the network. Each Router 2 may be available on different channelsand/or at different times. Each link in the network tree may use adifferent frequency if that is what works best. For example, node A mayfind that channel 20 works best for its communication with Router B, butnode C may find that channel 15 works best for its communication withthe same Router B. Thus, the adaptive frequency agility of the proposedscheme may be link-by-link, rather than system-wide.

In highly optimized systems, Routers 2 may coordinate their activitiesso that nearby Routers 2 operate at different times and/or at differentfrequencies. For many sensing applications, such optimization may beunnecessary or even counterproductive, as the data sources and sinks(typically Star nodes 1) may be on a very low duty cycle, and throughputrequirements may not be very stringent. Thus, in a typicalconfiguration, each Router 2 may run on its own pseudorandom schedule,with the possibility of packet collisions across Routers 2.Randomization of Frame Beacon timing and frequency as described abovewill prevent such collisions from occurring on a frequent or repetitivebasis. Such inter-Router 2 collisions, when they occur, may be handledby the IEEE 802.15.4 CSMA-CA scheme.

In one embodiment, nodes attempting to join the network may test thequality of available channels and pick the best two (a primary and asecondary) based on signal strength, direct sequence correlationquality, and similar metrics described subsequently. Once a node findsspecific channels that provide good connectivity with a parent, it mayselect those channels for communication. When feasible, the node maypick channels that are in different parts of the 2400-2483 MHz spectrumto gain the fall advantages of frequency diversity. The node mayschedule its activities to use these channels when they are available.

In an alternative embodiment, a node may simply always use the mostrecent channel that worked. The node may continue to use that channeluntil there is a communication problem. The result of this approach isthat individual nodes will tend to stick with working channels andquickly bypass channels that are problematic.

The choice between these two approaches may be driven by the stabilityof the radio environment, the amount of program memory available in thenodes, and similar factors. The two approaches may be mixed, forexample, with each approach corresponding to a mode of operation for agiven node. A node may switch between modes adaptively.

If a node's preferred channels prove problematic (as indicated by lackof acknowledgements in communications with a node's parents), the nodemay automatically re-survey the available channels and switch to adifferent pair of channels, or the node may simply switch to the nextavailable channel. Thus, over time system operation may adapt. Forexample, if there is an 802.11b system operating nearby, over time nodesmay detect interference on certain channels and may switch theiroperation to a different portion of the 2400-2483 MHz band. For example,if 802.11b is operating on channels 1 (2412 MHz), 6 (2437 MHz), and 11(2462 MHz), an adaptive 802.15.4 system may, over time, tend to move tochannels 15 (2425 MHz) and 20 (2450 MHz). If Routers 2 begin tointerfere with each other due to concentrating communications on certainchannels, the adaptive nature of the system will tend to spread use toother channels. Thus the system will over time move in a randomized waytoward an optimized equilibrium state, but one that will change withchanging requirements and with the environment.

Frequency Hopping

In some instances, regulatory requirements may preclude the use of AFAsystems. In such cases, a frequency hopping (FH) system (in whichdevices on the network may hop from one frequency to another in unison,in a set pattern, and on a set schedule) may be used. Although radiocommunication with FH may share some of the benefits of AFA, FH systemsmay have some disadvantages as applied to mesh networks. Maintainingbalanced operation on 50 or more channels (a regulatory requirement)requires substantial protocol overhead. Also, FH systems generally donot “learn” which channels work best and which channels are best avoideddue to cross-interference from other users of the spectrum. In fact,under FCC rules, a frequency hopper is expected to use all channelsequally and not avoid use of channels that are known to be problematic.Despite these drawbacks, FH is preferable to single-channel operation inmesh networks. Still, when regulations do not require FH, it ispreferable to use an AFA system, achieving the benefits of frequencydiversity without corresponding inefficient utilization of the radiospectrum and unnecessary use of battery power.

In one embodiment, the WSN architecture may utilize FH among 50 possiblechannels (0-49). The system may change state every 400 ms, or 2.5 timesper second as required by FCC rules. During this 400 ms, in a particularembodiment developed by the inventors, the radio may transmit data onits channel for up to 360 ms, may transmit an FH Beacon for up to 11.6ms, and may be idle for at least 28.4 ms. The system may hop accordingto a pseudorandom sequence (FH Sequence). In one embodiment, supportedhop sequences may include:

Sequence A

-   -   20,42,8,33,1,37,15,49,14,34,16,31,7,36,21,48,9,41,23,        5,22,39,13,38,18,43,3,44,25,2,28,47,0,29,10,27,12,30,        4,26,11,35,17,32,6,46,24,40,19,45

Sequence B

-   -   45,19,40,24,46,6,32,17,35,11,26,4,30,12,27,10,29,0,47,28,2,25,44,3,43,18,38,        13,39,22,5,23,41,9,48,21,36,7, 31,16,34,14,49,15,37,1,33,8,42,20

Sequence C

-   -   9,30,14,1,24,40,18,34,15,5,45,28,46,4,25,35,0,39,10,        20,38,13,31,12,48,33,21,36,3,47,16,2,19,43,7,49,6,29,        17,32,22,41,23,37,27,44,11,42,8,26

Sequence D

-   -   26,8,42,11,44,27,37,23,41,22,32,17,29,6,49,7,43,19,2,        16,47,3,39,21,33,48,12,3        1,13,38,20,10,39,0,35,25,4,46,28,45,5,15,34,18,40,24, 1,14,30,9

Sequence E

-   -   45,30,0,29,14,46,28,6,35,4,43,11,49,9,38,12,34,13,36,        18,3,21,42,27,10,40,25,5,24,8,26,7,32,47,15,41,20,39,        2,22,37,19,44,23,1,17,33,48,31,16

Sequence F

-   -   16,31,48,33,17,1,23,44,19,37,22,2,39,20,41,15,47,32,7,26,8,24,5,25,40,10,27,        42,21,3,18,36,13,34,12,38,9,49,11,43,4,35,6,28,46,14,29,0,30,45

Through software at the Host 4, the user may select which pseudorandomsequence is used.

In one embodiment, an entire WSN 100 may utilize the same hop schedule,with all interconnected Routers 2 hopping together. If multiple separateWSNs 100 are used within a single facility, each separate WSN 100 mayuse a different hop schedule. In another embodiment, the system mayallow different Routers 2 to operate on different hop sequences byselecting one of the available hop patterns for each Router 2.

FH Beacons may be used to establish the time base of the FH system. AnFH Beacon may contain one or more of the following:

-   -   Network ID    -   Session ID (that may be used to distinguish between network        communications sessions, such as when a network times out and        reforms)    -   Which FH pattern is being used (FH Sequence)    -   A hop index    -   How much time is left in the current hop (relative to the        network; this may help to synchronize the network and to correct        for drift)

FH Beacons may provide enough information for nodes to discover whichnetwork is transmitting the FH Beacons and the timing for that network.

FH systems generally hop on a fixed-length schedule withoutrandomization in the timing. While this is an acceptable strategy for asingle hub-and-spoke network, substantial crosstalk can result whenseveral mesh nodes share a single frequency hopping schedule. Forexample, beacons simultaneously transmitted at the beginning of eachfrequency transition would result in collisions between Routers 2. Thus,in such FH systems the timing of the beacons may be randomized within anetwork-wide CAP 402.

When FH Beacons are transmitted by multiple Routers 2 at a random timeduring each hop, they may begin to “clutter up” the shared channel byinterfering with other network traffic. In order to prevent this, thesystem may transmit the FH Beacon on the previous channel or thesubsequent channel in the shared frequency hopping sequence. FIG. 9illustrates transmission of the FH Beacon 451 on the previous channelusing a portion of Hop Sequence A as an example.

In one embodiment of an FH system, each 400-ms hop may comprise a 360-msdata state (or CAP 402) and a 40-ms idle or non-data state. Packettransmissions may occur during the data state; packet transmissions maynot begin during the idle state. At some time during the data state ofeach hop, a Router 2 or Gateway 3 may be “deaf” as it briefly returns tothe previous channel to transmit an FH Beacon 451. The time during thedata state at which this occurs may be random or pseudorandom; however,if the Router 2 or Gateway 3 is in the middle of a data transmission,reception, or transaction at the chosen time, the node may wait untilthe operation is completed before it returns to the previous channel totransmit the FH Beacon 451.

A further modification may be made so that all Routers 2 do not emit FHBeacons 451 on identical channels: Instead of the whole systemtransmitting FH Beacons 451 on the next or previous channel, differentRouters 2 may be instructed to send FH Beacons 451 on different offsets.For example, Router 2 (A) may be instructed to send an FH Beacon 451 onthe channel that is +25 channels in the sequence, while Router 2 (B) maybe instructed to send an FH Beacon 451 on the channel that is −13channels in the sequence. The FH Beacon offset may be set differentlyfor each Router 2, but once an offset is fixed for a Router 2, it mayremain that way. For example, if frequency hopping Sequence A is beingused and the system is at channel 20, and Beacon transmission at channel20 may interfere with other network traffic, Router 2 A may send an FHBeacon 451 on channel 43 (+25 in the sequence from channel 20) andRouter 2 B may send an FH Beacon 451 on channel 30 (−13 in the sequencefrom channel 20). This approach does not bias the system in favor of anyparticular channel.

For example, a 902-928 MHz FH implementation by the inventors utilizes a19.2 kbps FSK radio. During a 400 ms “frequency hop” window the radiomay: transmit data on its primary channel for up to 360 ms, transmit anFH Beacon 451 on its secondary channel for up to 11.6 ms, and remainidle for an inter-hop period of at least 28.4 ms. The radio may bephysically incapable of transmitting on more than one channel at anygiven time. By maintaining a fixed offset in the frequency table betweenthe primary and FH Beacon channels, this scheme may ensure that nochannel is occupied for more than 400 ms in any 20-second period asrequired by FCC rules.

Wireless Sensor Network Formation

WSNs may be configured in a wide variety of ways to address emergingmarkets in sensor networks. In the following sections, we describe morefully network formation in a WSN 100, including network initializationand network creation. We focus here on AFA systems; changes that may berequired for FH systems are also discussed. In the following discussion,we describe certain illustrative embodiments; however, thesedescriptions are purely illustrative and are not intended to belimiting.

Initializing the Network

In order for a WSN 100 to be initialized, the following steps may beperformed:

-   -   Appoint WSN Coordinators to perform functions such as network        administration, security management, address allocation, data        logging, and other functions. In a simple configuration, a        single device such as a WSN Gateway 3 will perform these        functions. In alternative configurations, these functions may be        performed in a distributed fashion by a collection of devices.    -   Select parameters for the network, such as AFA or FH Sequences        for the Coordinators, interval and dither for the beacons,        control channels, channels to be included in the network's        operation, and Network ID.    -   Place the WSN Coordinator(s) into service.

Once these steps have been completed, the next step in building anetwork may be for the Host 4 to initiate a “Session.” Sessions may benumbered starting at 1, increasing to 255, and then starting over again.The Session Number may be included in every Frame Beacon 401. If a nodesees a new Session Number, it may need to rejoin the network.

The Host 4 may have several choices when initiating a network:

-   -   Session Number. The Host 4 may need to keep track of Session        Numbers. One way may be to increment the Session Numbers from        one Session to another, with checks at the Host level to ensure        that two networks with the same Session Number are not operating        at the same time. The Session Number may be combined with a        unique Network ID that identifies the WSN 100 to distinguish it        from other WSNs 100 operating in the same vicinity.    -   Multiple Gateways. The Host 4 may support two or more Gateways 3        per Session. These multiple Gateways 3 may be capable of        operating independently from each other, thus providing        redundancy.    -   Node 16-bit ID. Each node in a WSN 100 may be assigned a unique        16-bit network ID. A 16-bit ID may be sufficient to identify and        address messages to a Router 2. A 16-bit ID may uniquely        identify a Star node 1 in the network;

however, in addition to the Star node's ID, the ID of its parent Router2 may also be needed to address messages to the Star node 1, asdescribed subsequently. The Host 4 may allocate IDs, and IDs may belocked to the Session Number. Doing this may make it easier for a Nodeto rejoin the network if needed. For example, if a Router 2 losesconnectivity to the network but then regains it, the Router 2 can reportthat it was previously Router X in session Y in network Z. If theNetwork ID (Z) and Session Number (Y) match, the Router 2 may be able torejoin the network with Router ID X, because IDs may be assigned onceper session (if they are locked to the Session Number and the NetworkID).

-   -   FH Sequence (in FH systems). If the Host 4 is reconfiguring an        existing network, it may keep the same FH Sequence. If multiple        networks are operating in the same facility, it may be best to        use different FH Sequences across the various networks. It would        make things easier if we could use the same FH Sequence for all        networks and coordinate their timings so that they never        interfere with one another. However, FCC rules require that the        various FH networks operate independently, not in a coordinated        fashion. Thus, there may be a need to define a set of FH        Sequences that are more or less “orthogonal” to each other,        meaning that if they happen to line up in time, they will not        collide with each other in a repetitive way. The FH Sequences        may also be designed to include only large hops (in support of        frequency diversity).    -   Once the Host 4 initiates a Session, Gateways 3 may begin to        cycle through the control channels (or, in an FH system, the        selected FH Sequence), transmitting a Beacon on each frequency.

Creating the Network

After at least one Gateway 3 is in place, the network creation processmay begin. The network may inherently build a tree-like networkstructure branching out from each Gateway 3. Each Router 2 may becapable of checking for new additions to the network.

Acquiring the System's Time Base

Devices in a WSN 100 may have a shared synchronized time base, andchannel use may be scheduled based on that shared time base.

When a Router 2 or Star node 1 first awakens, it may need to acquire thetime base of the system. To enable this, Routers 2 that have alreadyjoined the network may transmit Frame Beacons 401, as described earlier.Until some other nodes detect a Frame Beacon 401 from a Router 2 andattempt to join the network (as a child of that Router 2), the primaryfunctions of a Router 2 may be to transmit these Frame Beacons 401 asadvertisements that a WSN 100 is available and to allow other devices toevaluate their connectivity to that Router 2.

A node that wishes to join the network may listen to one of the controlchannels (or, in an FH system, a selected channel of the 50 availablechannels). Eventually, a Frame Beacon 401 (or FH Beacon 451) may betransmitted on the channel to which the node is listening; this willallow the node to acquire the time base of the system.

If no Frame Beacon 401 (or FH Beacon 451) is detected, the node may bein a radio null. To attempt again to acquire the system's time base, thenode may select a different channel and listen again. If the node triesto acquire a Beacon on several different channels and fails, the nodemay back off for a time and then retry those channels. If the node stillcannot acquire a Beacon, the node may back off for a longer time beforeretrying. The backoff time between retries maybe changed, e.g.,increase, between each set of retries.

If the system is in the middle of a data transmission (from Node to Host4 or vice versa) during the scheduled Beacon transmit time, the Router 2may wait to send the Beacon until after the data has been transmittedand acknowledged.

Once a node acquires the time base of the system, the node may keepaccurate track of the time, even if the node is asleep, so that allnodes know when to wake up, when to transmit, when Frame Beacons 401 areexpected to be transmitted, etc. Each node may be synchronized to itsparents; thus, the system time may remain roughly synchronized all theway up to the Host 4.

Joining the Network

Once a node detects a Frame Beacon 401 from at least one Router 2, itmay be able to communicate with the network at least through that Router2. The node may wait on the same channel until it hears from all nearbyRouters 2 in the network. If the node is locked to a particular network,it may ignore Frame Beacons 401 from Routers 2 that are not in thenode's designated network by checking for a designated Network ID. Thismay allow several networks to operate nearby without nodes trying tojoin any and all available networks. The default setting may be to jointhe first network from which the node detects a Beacon. However, if anode that was previously joined to a network is trying to rejoin anetwork, it may attempt to rejoin the network to which it was previouslyjoined.

The procedure to join the network may include security checks, such asfor authentication. Security features are described subsequently.

Once a node has associated with the network, it may acquire its parentRouters 2. In joining the network, nodes may need to detect Beacons frommultiple Routers 2 in order to perform connectivity assessments andchoose parent Routers. In one embodiment of an FH system, a newly joinednode may listen for an FH Beacon 451 on the previous channel (since,once it acquires the network, it may now know that an FH Beacon 451 willbe transmitted on the previous channel).

In one embodiment, each device may start as a generic node, that is, nodistinction may be made between Routers 2 and Star nodes 1 when theyfirst join the network. Once a node has joined the network, differentoperations may be performed on or by the node based on the device type(Router 2 or Star node 1). If the node is a Star node 1, then it mayreport its feature set and begin its work (for example, collecting andreporting sensor data if it is a sensor-attached Star node 1). If thenode is a Router 2, it may report its Router configuration to itsparents and begin to transmit Beacons.

Security Features

To prevent spoofing and other security breaches, it may be desirable toadd some form of security to the WSN 100. There are a number of featuresthat can be added to introduce security, including authentication andauthorization of devices as they attempt to join the network andencryption of messages as they pass within the network.

A number of established schemes exist for authentication, authorization,and encryption. Each method has its own benefits and drawbacks, some ofwhich are discussed below.

Application Scenario

If only authenticated devices are allowed to join the network, then asubscription service may be established in which only subscribers thathave paid a fee can access the security keys needed to authenticatedevices and communicate within the network.

Certain features may be required in a mesh network security scheme forvarious application scenarios including:

-   -   Limiting use of the mesh network to devices that are known to a        Trust Center (i.e., the device or service entrusted with        security functions).    -   Restrictions that make it impossible to build counterfeit        devices.    -   Support for authorization over the Internet.    -   Low-overhead encryption for WSN messaging.

Symmetric Key Encryption

Symmetric key encryption may be used to authenticate network devices andencrypt network communications. The symmetric key may be a 128-bit keyimplemented by the Node's hardware. The 802.15.4 specification allowsfor AES 128-bit key encryption. Some transceiver implementations, suchas the Chipcon CC2420, support encryption in hardware, and such deviceshandle 128-bit symmetric keys without additional hardware or processoroverhead.

To improve security, the security scheme may use multiple symmetrickeys. A network-general key may be used for encrypted communicationbetween authorized devices within the network. In addition to thenetwork-general symmetric key, a symmetric key may exist for each Node.This Node-specific symmetric key may be known only to that Node and tothe Trust Center. The Trust Center may maintain a database (which mayitself be encrypted for security) containing the Node-specific symmetrickey for each Node that has been pre-authorized to join the network. EachNode may have its own symmetric key, used both for encryption anddecryption.

In order to improve security further, the network-general symmetric keymay be changed periodically (such as once per hour), in case anunauthorized device manages to obtain the key. One way to do this may befor the Trust Center to change the key at a scheduled time withoutnotifying any devices on the network. This may result in a new networksession being established, which may in turn require all devices to dropout and rejoin the network. This method is straightforward, butrebuilding the network may be undesirable (for example, due to batterypower needed for rebuilding, in addition to the interruption in networktraffic).

Another way may be for the Trust Center to send a message to each Nodeusing that Node's Node-specific symmetric key. This message may containthe time of the next key change and the new network-general symmetrickey that will be in use at that time. The Trust Center may beresponsible for receiving acknowledgments from each Node. This methodmay result in increased network traffic for a period of time prior toeach key change, but has the benefit that it is unlikely to require therebuilding of the entire network. Should a device not receive thenotification of the key change, that individual device may drop out ofthe network (when the new key comes into effect) and may need to rejointhe network.

Messages between a parent Router 2 and a Child node may be encryptedwith the parent's symmetric key without creating excessive storagerequirements in the Child nodes. The parent's keys may be sent to thechildren from a Trust Center that knows both the child's and theparent's symmetric key, using the child's key to encrypt a messagecarrying the parent's key. The parent's key may also be alteredperiodically by the Trust Center using the old network key plus anode-specific key to encrypt a message that delivers a new key.

Public Key Encryption

Public key encryption systems (also known as asymmetric key encryptionsystems) use different keys for encryption and decryption. Public keyencryption offers a way to authenticate devices and encrypt messageswithin a WSN 100.

The authentication procedure may be shortened somewhat if the TrustCenter maintains a secure database containing the public keys for allpre-authorized Nodes. The authentication process may also be shortenedif the authentication is not reciprocal (i.e., the Node does notauthenticate the Trust Center).

In addition, if a Node's public keys are somehow mapped to the Node'sserial number, this may provide another authentication method. If amessage appears to come from a Node with a certain serial number, butthe message cannot be decrypted with the public decryption key matchingthat serial number, then the message must not have been encrypted withthe private encryption key matching that public decryption key. Thus,the message may have been spoofed.

Once a Node has been authenticated and allowed to join the network, thesame keys may be used for encrypted communication with other devices inthe network, as long as the devices share their public keys with eachother.

Freshness

Freshness may be provided by sequentially numbering messages from Nodes.Devices receiving messages may remember the sequence number of the lastreceived message from a Node. If the sequence number is not increasing,new messages may be suspect. The cost of the sequence number may includethe power required to transmit the additional information, plus thememory in the receiving device to track sequence numbers from alldevices in communication.

A Hybrid Authentication/Encryption Scheme

Public key encryption schemes may be highly secure, but may have thedrawback that encrypted communication can occur only after public keyshave been shared between devices. This may generate additional traffic,complexity, and memory requirements in the Nodes (to store the keys oftheir neighbors). Asymmetric keys may also complicate network setup anddebugging and may add latencies to communications for encryption schemesthat are not supported in hardware. Thus, there are advantages in usingasymmetric keys to set up the network, but then using symmetric keys fornetwork communications once the devices are authorized. This sort ofhybrid security scheme is relatively common; well-known hybrid systemsinclude HTPS/SSL (Internet) and PGP (email). For example, forauthentication, public key encryption may be used, but for generalnetwork communication, symmetric key encryption may be used. For certainmessages to and from the Trust Center (and designated only for thatNode, but not for other devices), public key encryption may be used.

The basic idea of a hybrid authentication/encryption scheme is depictedin FIG. 10. In the example in FIG. 10, Node A may receive an unencryptedbeacon from a Router (S21). Node A may send its LongID and its publickeys, if needed, to the Trust Center via a Router (S22). If the TrustCenter maintains a public key database, it may look up Node A's LongIDand retrieve Node A's public encryption key (S23). The Trust Center maysend to Node A the Trust Center's public keys and the network symmetrickey, encrypted with Node A's public encryption key (S24). When Node Areceives the message, Node A may decrypt the message, thus obtaining theTrust Center's public keys and the network symmetric key (S25). Node Amay send an acknowledgement to the Trust Center via a Router, encryptedwith the Trust Center's public encryption key (S26). Node A may thenparticipate in the WSN, sending and receiving messages using the networksymmetric key (S27).

The network's symmetric key may be changed periodically to improvesecurity.

If the Trust Center does not maintain a secure database containing thepublic keys for all pre-authorized Nodes, Node A may need to send itspublic keys (S22), since the Trust Center may not yet have these keys.

To verify that a Node attempting to join the network is a user-specificnode, as well as to make it more difficult to spoof Nodes or messages inthe network, each Node may incorporate a user-specific encryption key.When a Node joins the network, it may encrypt or sign messages usingthis user-specific private key. The matching user-specific publicdecryption key may be published and used to verify that the Node isindeed a user-specific Node. Additional signatures may be created forother vendors of Nodes as needed.

If private keys are physically stored in the Node, they may be read fromthe Node and thus may be discovered. Specialized processor componentsare available that purport to solve this problem by storing the code inencrypted form and by hiding the decryption key in special hardware thatcannot be read.

Security may also be improved if the user-specific decryption key is notpublished. The message signature may instead be passed to a network orInternet trust center for verification. Verification may be performed ona secure server, and a second key may be used to sign the response. Thepublic half of the second key may be published so that networked devicesmay see that a Node has been verified.

To prevent another type of spoofing, a random number may also beincluded in the payload of the message. As this number is decrypted,read, and sent back, this may provide an additional check against a Nodepretending that it is another Node or the Trust Center. Additionalsecurity may be achieved by injecting a second random number.

Connectivity Assessments in an AFA System

As discussed above, one aspect of the invention involves the use ofconnectivity assessments by nodes to determine communicationrelationships within a WSN 100. In one embodiment, a node attempting tojoin a WSN 100 may listen on designated control channels for FrameBeacons 401. As noted earlier, Frame Beacons 401 may include schedulinginformation for future Frame Beacons 401 so that nodes can predict theavailability of a given Router 2. Once a node hears Frame Beacons 401from multiple Routers 2, the node may perform a connectivity assessmentto each such Router 2. Such assessments may be performed in differentways as discussed below and used by the node and/or the Gateway(s) 3 toselect the node's parents and/or preferred communication channels.

To determine a quality measure of a received signal, each packet may bedelivered from the IEEE 802.15.4 PHY (or equivalent) with a SignalQuality Indicator (SQI), incorporating factors such as received signalstrength, pseudonoise correlation, and other signal quality metrics thatmay be built into the radio.

Quick (One-way) Assessment

A Quick Assessment may provide a simplified assessment of the linkquality to all nearby Routers 2. It may be used to determine whichRouters 2 are the best candidates for Detailed Assessment. QuickAssessment may also be used for Nodes that are mobile.

Quick Assessment may be accomplished by running a receiver (such as aStar node 1) for a period covering a variety of channels. During theseperiods, a Node may collect statistics on the number and quality ofFrame Beacons 401 received from all Routers 2 in range.

Two statistics may be accumulated for each Router 2: Beacon_Count, whichis the number of Frame Beacons 401 received, and SQI_Sum, which is anindicator of link quality. These may then be combined in two steps:

-   -   1. Convert SQI_Sum to SQI_Average, and then use a table or        function to convert SQI_Average to an SQI_Factor in the range of        0 to 1.    -   2. Use Equation 2 to estimate the probability of reception.

3. $\begin{matrix}{{Probability} = {\frac{Beacon\_ Count}{Beacons\_ Expected} \times {SQI\_ Factor}}} & (2)\end{matrix}$

SQI_Factor is not necessarily a linear function, and may notsignificantly affect the result unless link quality is low enough to becorrelated with experience of marginal connectivity.

The probabilities may be expressed as percentages, essentially floatingpoint numbers between 0 and 1. They may alternatively be recast tointeger form scaled to the range of 0 to 255. One-byte probabilities maythen be multiplied together and the high-order byte used as theresultant probability.

For power savings, the sampling may be done in two phases. In the firstphase, the Node may first sample one or more channels to get a generalidea of which Routers 2 look promising. In the second phase, the Nodemay collect detailed data from only those Routers 2 that lookedpromising in the first phase. Power may be saved in the second phase byforecasting the pseudorandom times and frequencies when Frame Beacons401 will be transmitted and running the microprocessor and receiver onlyat those times and frequencies.

Detailed (Round Trip) Assessment

A Quick Assessment may be based on one-way connectivity from a Router 2to a Node. A more accurate result may be obtained by performing aDetailed Assessment based on two-way connectivity. This may cover thecommon case where connectivity in one direction is acceptable, butconnectivity in the reverse direction is problematic.

For a Detailed Assessment, the Node may pick a few candidate Routers 2based on the Quick Assessment. It may then conduct a two-way test bysending a packet to each of the candidate Routers 2 and seeing whetheran ACK comes back in response. Scoring may be done as in the QuickAssessment.

SQI measurements described above may be from Router 2 to Node. A two-waySQI measure may be more accurate and/or provide useful information, andthis can be handled be including the Node-to-Router SQI in theRouter-to-Node acknowledgement packet.

Round-trip connectivity is likely to be somewhat worse than one-wayconnectivity. Thus, a Quick Assessment may normally give higherprobabilities than the corresponding Detailed Assessment. For thisreason, it may be best not to make decisions based on comparing Quickand Detailed Assessments.

On command from a Router 2 or a Gateway 3, the Node may report itsConnectivity Assessment. A given report may include an indicator of howthe Assessment was calculated (Quick or Detailed), along with the numberof samples used to create the Assessment.

Selecting Parents Using SQI

Connectivity Assessment may not be a practical option for devices thathave very little memory, or for devices that are mobile and need to makequick routing decisions. Such devices may select parents on a permanentor temporary basis using SQI alone.

In one embodiment, a newly joined node may listen for a specified amountof time to each Router 2 that it has selected as a candidate for itsparent Routers 2. Once the node has gathered SQI information for severalRouters 2, such as five Routers 2, the node may sort the nodes by SQI.It may then send a request to the Router 2 with the best SQI, askingthat Router 2 to become its primary parent. If its request is denied,the node may continue down the list until it establishes a primaryparent. If the node gets to the bottom of the SQI list withoutestablishing a primary parent, the node may scan again for newcandidates to become its parent Routers 2, performing SQI assessments,ranking Routers 2 by SQI, and sending requests for a primary parentuntil the node's primary parent is established.

Once the node's primary parent has been established, the node may gothrough the list of ranked Routers 2 again in a similar fashion, thistime excluding its primary parent from the list, to establish itssecondary parent. Although possible, the same Router is typically notused as both primary and secondary parent, as this would be redundant.

The node may be able to function without a secondary parent if nosuitable secondary parent is found; however, a primary parent may berequired for communication with the network. If no suitable primaryparent is found after numerous retries, the node may back out of thenetwork. It may then re-associate with the same network or attempt tojoin a different network.

In one embodiment of the system, a node without a secondary parent maybe able to join the network, but the node may continue to seek asecondary parent on a regular basis until suitable candidates are foundand a secondary parent is established. This may also address the issueof Routers 2 that join the network early on, when few other Routers 2are available to become parents; as Routers 2 are added to the network,Routers 2 that have not yet selected secondary parents may continue tosearch until they have located secondary parents.

Once a Router 2 has accepted a node as its child, the Router 2 may senda packet to the Gateway 3 indicating its responsibility for the childnode (as primary or secondary). A parent Router 2 may give negativeacknowledgment to nodes that incorrectly think they are children of thatRouter 2.

Connectivity Assessments in an FH System

The concepts of Connectivity Assessment are similar in a FHimplementation, but with some differences in detail.

In an FH implementation, the Frequency Hopping schedule may be shared byall Routers 2 that hop together in a WSN 100. Each Router 2 may attemptto transmit an FH Beacon 451 at a pseudorandom time during eachfrequency hop.

A probabilistic approach may be used to assess the connection between anode and its nearby Routers 2. For example, suppose a node expects toreceive 50 packets from a Router 2 over a given period, on each of theavailable 50 channels. If it receives 48 of those packets, it hasmeasured 48/50=96% connectivity. This probability may be discounted ifmeasured signal quality is low, reflecting a link that might beparticularly sensitive to changing conditions.

For a valid connectivity assessment, a variety of frequencies spreadacross the band may be sampled.

Quick Assessment may be accomplished by running a receiver (such as aStar node 1) for a period covering a variety of hop channels, withreasonable ranges including 6 to 50 hops. During these periods, a Nodemay collect statistics on the number and quality of FH Beacons 451received from all Routers 2 in range.

Sampling fewer than 50 channels may save power. For example, tenchannels may be sampled for a Quick Assessment; this may likely a resultthat is almost as accurate.

For power savings, the sampling may be done in two phases. In the firstphase, the Node may first sample a handful of channels to get a generalidea of which Routers 2 look promising. In the second phase, the Nodemay collect detailed data from only those Routers 2 that lookedpromising in the first phase. Power may be saved in the second phase byforecasting the pseudorandom times when FH Beacons 451 will betransmitted and running the receiver only at those times.

For Detailed (round trip) Assessment, the most accurate result may beachieved by testing all 50 channels, but for power savings, it may bemore practical to use a sampling approach on (for example) 10 or 25channels.

Ongoing Assessment and Time Synchronization

The Child node's parent Routers 2 may acknowledge heartbeats, asdescribed subsequently. This provides a “free” way to test connectivitycontinuously.

Heartbeats may be scored in batches of, say, 25, using the same metricsas the Detailed Assessment. Heartbeat success rate may be reasonablyconsistent with the original Assessment when the connection wasestablished. If this is not the case, the Child node may report thatfact to the Host 4 and wait for further instructions.

Relative clocks between nodes and their parents may drift over time. Ifclock crystals are accurate within 20 ppm, this means a clock may drift0.02 milliseconds per second. Two crystals drifting in oppositedirections may drift as much as 0.04 milliseconds per second in relationto each other. Each minute, these drifts may add up to 2-3 milliseconds.If a parent-child connection is lost for a few minutes, these kinds oferrors may add up quickly.

A Router 2 that monitors the channel continuously may resynchronize itsclock to its parent every time it receives a Beacon from another Router2. Thus, Routers 2 may keep to a tight schedule in relation to eachother.

For nodes that are children of one or more Routers 2, it may be best toresynchronize with each Router 2 every minute or two. Various techniquesmay be used. Some options may include:

-   -   Turn on the receiver until a Beacon is received.    -   Forecast the timing of Beacons by duplicating a Router's        pseudorandom timing of these Beacons. Listen for a Beacon at an        expected time, leaving some extra time before the Beacon to        account for expected clock drift since the prior time        synchronization, as illustrated in FIG. 11. A child node may        predict expected Beacon transmit time 501 by knowing the        schedule for its parent, accounting for a pseudorandom dither as        described previously. However, because there is some uncertainty        in the relative clocks of a node as compared to its parent,        there is some uncertainty in the actual transmit time and        receive time (shown as Random Variance 502 in FIG. 11), so the        child node may need to wake up 503 early enough to account for        this uncertainty. In addition, the child node may need to allow        time for its microprocessor to wake up 504, its radio receiver        to warm up 505, as well as time to calculate the dither (or find        the appropriate entry in a dither lookup table, as described        earlier), and additional time may be allowed for calibrated        clock drift and Beacon transmission length 506. Thus, the child        node may need to remain awake and listening for a Beacon for a        period of time 507 before and after the expected Beacon transmit        time. The sequence may be as follows:    -   Child calculates wakeup time, accounting for all of the expected        latencies.    -   Child goes to sleep for a period of time.    -   Child wakes up at precalculated wakeup time 503.    -   Turn on the microprocessor 504, conduct any processing that is        needed on wakeup (such as reading a sensor).    -   Warm up the radio 505.    -   Start listening at some time during the period prior to when the        parent is expected to transmit its beacon.    -   Under some circumstances it may be useful for a node to request        a Beacon explicitly from a Router 2 or Gateway 3. For example, a        heartbeat packet may optionally request a Beacon following its        acknowledgement. This approach may be more power efficient in an        FH system for a Star node 1 that is generating heartbeats        anyway.

It may be best for a node to maintain a separate time base with respectto each of its parents. For example, a Router 2 might maintain threeindependent time bases: one with respect to its primary parent, a secondwith respect to its secondary parent, and a third with respect to itschildren.

Microprocessor clock accuracy is typically specified as a range, such as±20 ppm. In practice, the crystals driving the clocks may have moreprecision. For example, one part may be plus 8 ppm, while another partmay be minus 17 ppm. Thus, in some hardware implementations it may beuseful for a node to calibrate its clock drift relative to each of itsparents by measuring the clock drift between pairs of timesynchronization points. Accuracy may change over time due to agingeffects, so it is best to recalibrate the drift periodically. Clockdrift may also change with environmental factors, such as temperaturechanges in both the child and parent nodes. Such secondary effects maybe separately calibrated out of the system, for example by explicitlymeasuring the node's temperature, or tolerated in less optimizedimplementations as something that reduces the intrinsic precision of thenode's timer.

Routers Form a Backbone

Routers 2 in range of a Gateway 3 may detect Beacons with a new SessionNumber. After confirming that this is not a communication error (such asa spurious reception from a nearby network), these Routers 2 may stoptransmitting Beacons from previous sessions, if any, and may stopperforming any functions related to previous sessions. This lack ofresponsiveness may percolate through the node's descendants and maycause the overall network (if one already exists) to timeout.

In an FH system, a Router 2 may detect FH Beacons 451 with a new SessionNumber if the FH Sequence remains the same. If the FH Sequence isdifferent, the Router 2 may stop hearing FH Beacons 451 from its parentsat all and its parents may become unresponsive. In that case, the Router2 may follow the power-up procedure to discover the FH Sequence and soforth.

When a Router 2 observes Beacons with new Session Numbers, it may verifythat it is not picking up stray packets from a different network byconfirming that Beacons from its parents have entirely disappeared andthat its parents are unresponsive in general. (Even if its parents areawake, they may be operating with a new Session Number and/or newNetwork ID and may thus no longer be identifiable as the Router'soriginal parent.) Once the Router 2 has ascertained that the new Beaconsare indeed replacements for the old, it may begin a connectivityassessment.

Each Router 2 may include a table in the following form: Quick JoiningAssessment Delay x > 90%  0 sec x > 75%  60 sec x > 60% 120 sec x > 50%180 sec Otherwise Keep waiting

When a Router 2 sees a Beacon for a new session, it may conduct a QuickAssessment to determine if it should join the network. (This may notapply to Gateways 3.) According to the table above, if it sees at least90% connectivity to another Router 2 (or directly to a Gateway 3), itmay join immediately. If not, it may continue with a Quick Assessmentfor another 60 seconds to see if it finds improved connectivity,presumably due to other Routers 2 joining the network. If, at the end of60 seconds, it has at least 75% connectivity to another Router 2 (or toa Gateway 3), then it may join the network. This assessment may continuedown the table. If the Router 2 has not yet joined the network, and newRouter(s) 2 appear with higher quality than previously observed, thedelay may be reset and the process restarted.

A probabilistic approach allows connectivity assessments to be chained,as shown in the example in FIG. 12. In FIG. 12, the probabilities shownare Connectivity Assessments indicating the probability that a packetsent by a device will reach another device. Thus, for example, if Router2 b (B) sends a number of packets to Gateway 3 (A), A is likely toreceive 60% of the sent packets, while A is likely to receive 80% of thesent packets from Router 2 c (C). Likewise, if Router 2 d (D) sends anumber of packets, Router 2 b (B) is likely to receive 90% of them. In aconnectivity assessment, these probabilities can be multiplied toestimate the likelihood that a packet sent by one device will reach anyother device in the network. For example, the probability that a packetsent by Router 2 e (E) will reach the Host 4 is 90% * 80%=72% if thepath E-C-A-Host is used and 85% * 60%=51% if the path E-B-A-Host isused. The tables 5 in FIG. 12 list the probabilities for all relevantpaths from each device, including paths through the parents to theGateway 3 A and paths to the node's descendant Routers 2. Note thatthese probabilities may reflect the chance that a single packet willreach its destination without retries. Actual performance may be betterthan calculated with retries on different frequencies and attempts totransmit on secondary paths.

In this case, it is interesting that the path D-C-A (64%) is a betterconnection choice than the path D-B-A (54%), even though the quality ofthe connection D-B (90%) is better than the quality of the connectionD-C (80%). That is because the downstream connection to the Gateway 3 ismuch better from C than from B. Thus, it may be preferable to selectparents based on the total quality of the connection to the Gateway 3,not just the connection quality of the closest hop.

Once the Quick Assessment indicates that the Router should join thenetwork, the Router 2 may execute a Detailed Assessment to select anappropriate primary and secondary parent. (This selection may be basedon connectivity to the Gateway 3, as shown in FIG. 12. However, we mayestablish an additional condition such that a Router 2 may not attach toanother Router 2 unless the Quick Assessment passes the test above.)Then the Router 2 may request a 16-bit Router ID from the Host 4. TheHost 4 may be responsible for allocating unique 16-bit Router IDs, suchas by starting at 1 and incrementing from there. When Router IDs need tobe recycled, all networks connected to a Host 4 may be re-initiated,with new Session Numbers (and, in the case of FH systems, different hopsequences).

With each Router 2 having a primary and secondary parent, there may be aclear path back from every Router 2 to the Host 4, with each Router 2simply passing messages upward to one of its parent nodes until messagesreach the Gateway 3 and then the Host 4. The path in the otherdirection, i.e., from the Host 4 to each Router 2, may use an additionalscheme that is shown diagrammatically in FIG. 12.

In FIG. 12, tables 5 in the boxes provide routing from the Host 4 tooutlying Routers 2 (and from each Router 2 to the Host 4 via the Gateway3 A). Routing from the Routers 2 to the Host 4 is indicated by primary(solid) and secondary (dotted) lines. Note that Gateway 3 (A) maycalculate the entire tree by building on the routing tables found in itstwo children Routers 2 b (B) and 2 c (C). Also, note that Router 2 b (B)gave priority to a direct connection to Router 2 f (F), even though itsprobability is lower than an indirect connection. A direct connectionmay be preferable because it is possible for Router 2 b (B) to directlyvalidate that Router 2 f (F) received the message.

This scheme outlined in FIG. 12 has two basic purposes.

-   -   1. It provides a way to route messages from a Gateway 3 to its        Routers 2.    -   2. It provides a way to route messages between Routers 2. For        example, to send a message from Router 2 f (F) to Router 2 e        (E), the message may be sent from Router 2 f (F) toward the        Gateway 3 until it reaches Router 2 b (B). Since there is an        established path from Router 2 b (B) to Router 2 e (E), the        message may then be directed to Router 2 e (E) without involving        the Gateway 3 or the Host 4.

Another way of determining the routing may be to assign static weightsto each path segment between the Gateway 3 and a node. For example, aweight of 1 may be assigned to each primary relationship and a weight of100 may be assigned to each secondary relationship. For each pathbetween the Gateway 3 and a node, therefore, the weights of each pathsegment may be summed up to provide a total path weight. For example, inFIG. 12, the path A-C-D-F would have a weight of 1+1+1=3, while the pathA-B-F would have a weight of 1+100=101. The path with the lowest totalweight may be selected as the preferred route from the Gateway 3 to thatnode and stored in a routing table. Each Router 2 may maintain a routingtable for all of its subordinate nodes. As new Routers 2 are added tothe network, path weights may be rechecked to ensure that the best path(i.e., the path with the lowest total weight) is always used as thepreferred route to the and from the Gateway 3.

Nodes Connect to Router Backbone

Once a Router 2 backbone is in place, nodes may connect to Routers 2.The nodes may join the network using a procedure similar to thatdescribed earlier for Routers 2, including retry and backoff proceduresand association requests. This may occur in the following steps:

-   -   3. Acquire the time base of potential parents, or verify that it        has not changed by reading at least one Beacon.    -   4. Perform a Quick Connectivity Assessment to identify        candidates for primary and secondary connection.    -   5. Perform a Detailed Connectivity Assessment to select primary        and secondary connection. Connectivity Assessments may be        compared by considering the link quality to immediate        prospective parents, optionally also considering the prospective        parents' link quality to one or more Gateways 3.    -   6. Use 802.15.4 MAC to attach to selected Routers 2. This may        result in a two-part address for Star nodes 1—16 bits to        indicate its parent Router 2 and another 16 bits to indicate the        address of the Star node 1 within the Router's sphere of        influence. In one embodiment, each Router 2 may have its own        sphere of influence. Each Star node 1 may be in two spheres of        influence, a primary and a secondary.    -   7. Inform the Host 4 that the node has joined the network,        including the Connectivity Assessment results and other        application-specific information.

This entire process may be completed without ever sending a message tothe Host 4, although there are cases in which the Host 4 may need to getinvolved in setting up a connection. For example, a Router 2 may nothave the memory or bandwidth to support additional connections. In thiscircumstance, the Router 2 may report the situation to the Host 4application and may await further instructions. Similarly, it may be theresponsibility of the Host 4 application to detect opportunities forload balancing and instruct Routers 2 and Star nodes 1 to reconfigureaccordingly. Additionally, the Host 4 may act a security Trust Center toallow the node to join the network.

The node may select its primary and secondary Routers 2 based onassessments as described above and may connect to those Routers 2 usingtechniques that are supported by the 802.15.4 MAC. A minimum thresholdmay be used to decide whether it is worth using power to connect to aparticular Router 2. If there is some connectivity but no Router 2 issuitable, the node may persistently attempt (within reason) to reportthis fact to the Host 4.

As long as a node can hear from at least one Router 2, the node may senda request to join the network. For an optimal connection, the node mayprocess packets from all Routers 2 within radio range so that the nodemay perform a Detailed Assessment.

When a node first joins the network, it may be desirable to redo theQuick Connectivity Assessment a few minutes later. This may cover thecase where the node joins the network while the Router 2 backbone isbeing built. In this case, substantially better connections to the Host4 may be available a few minutes later.

A node may also conduct a Quick Connectivity Assessment periodically,such as every 30 minutes, to look for large changes in connectivity.

A node may periodically issue heartbeats to validate connectivity to itsprimary and secondary parents. If connectivity degrades substantially,the node may redo the Connectivity Assessments to validate that nobetter links are available.

Building Routing Tables

Once Child nodes have been added to the network, routing tables may bebuilt. These routing tables may contain information about primary andsecondary parents for each device in the network, as well as data onroutes to and from each device. This may allow packets to be rerouted ifnecessary and the network to be reconfigured or rebuilt if conditionschange (such as significant changes in SQI readings), if networktopology changes (such as a Router 2 dropping out), or if networkconnectivity is lost. Routing tables may be built as described earlier,using weighting of path segments from Gateways 3 to the node.

When a Child node joins the network, it may pass information about itsprimary and secondary paths, including path weights, to its parentRouters 2. The parent Routers 2 in turn may store this information andadd their primary and secondary path weights to the information and passit up to their parent Routers 2. This may continue until the informationreaches the Host 4, providing information to build routing tables ateach Router 2 for all of its subordinate devices.

Each device may know its best path to the Host (using the earlierconnectivity assessments). This information may be used to preventcircular routing. Devices can be instructed to reject paths that containthemselves to prevent loops (i.e., devices may include instructions notto become children of their own children). For example, if Router 2 (B)tries to become the child of Router 2 (D), but Router D's path to theHost 4 includes Router 2 (B), Router 2 (D) can reject Router 2 (B)'srequest (because this would create a path from D that goes to B and thenfrom B to D itself).

Routing tables may include addressing information that may contain ashort ID address for each Router 2. Star node 1 addresses may be in twoparts. The first part may refer to the address of a Star node's parentRouter 2, and the second part may refer to a short address for the Starnode 1 used by its parent Router 2. For example, Star node 1 (C) that isa child of its primary parent Router 2 (A) may be referred to as A, C.With two-part addresses of this form, routing tables in the WSN 100 neednot refer to star nodes; the address of the parent router is sufficient.Substantial memory and table maintenance can be saved in this fashion.The two-part address may be stored on the Gateway 3 or Host 4 andrequested by Node and Host 4 applications as needed.

Wireless Sensor Network Operations and Communications

In the following sections, we discuss basic network operations andcommunication in a WSN 100. We focus here on AFA systems; variationsthat may be appropriate for FH systems are also discussed. In thefollowing discussion, we describe certain illustrative embodiments;however, these descriptions are purely illustrative and are not intendedto be limiting.

IEEE 802.15.4 radios are specified in three types: 250 kbps operating inthe 2400-2483 MHz band, 40 kbps operating in the 902-926 MHz band, and20 kbps operating in the 868 MHz band. In the future, a 250 kbps variantat ˜900 MHz and other variants may also be specified.

When frequency hopping is used, in one embodiment using Chipcon CC1000transceivers, the system may operate at 38.4 kbaud. However, the radiomay be capable of operating at 19.2 kbaud or 76.8 kbaud, and in anotherembodiment these rates may be enabled with a software upgrade.

In one embodiment, frequency hopping may be handled in OSI level 2. Whenthe network or application needs to send a packet, it may initiate therequest without regard to the position in the hop pattern, thusresulting in a system that does not favor one frequency over anotherover time. One exception to this may be that layers above OSI level 2may wait for the next hop during the backoff-and-retry procedure. If amessage is sent by a node but no acknowledgment is received, the systemmay wait for a CAP 402 on another channel and may resend the message.

Star nodes 1 may operate on a low duty cycle to conserve battery power,transmitting heartbeats (described subsequently) to their parent Routers2 at intervals such as once per minute. Most of the time, Star nodes 1may be “asleep.” When they awaken, if they have messages to transmit,the Star nodes 1 may initiate communication, transmitting messages totheir parent Routers 2 to be propagated toward the Host 4.

Routers 2 may not normally propagate heartbeats or transmit “nodepresent” messages when a heartbeat is heard. Instead, in order to limitbandwidth consumption, Routers 2 may propagate messages toward the Host4 by exception when a child's heartbeat is not heard.

As a network grows, particularly when it is a network with frequentcommunication (such as a large network of nodes that frequently reporttemperature and humidity data), the amount of traffic to the Gateway 3and Host 4 naturally may increase. The amount of traffic may nonethelessremain small, since the data packets from a given node may be relativelysmall (tens of bytes) and/or infrequent.

Packet Formats

In a WSN 100 there may be four protocol layers: APP, NET, MAC, and PHY.As shown in FIG. 13, for each packet 600 that is sent, each layer mayencapsulate the layer above, adding a header and, in some cases, afooter. The header, packet payload, and footer (if any) for a layertogether may constitute the Protocol Data Unit (PDU) 601 for that layer.The PDU 601 may then be passed to the next layer, where it may becomethe Service Data Unit (SDU) 602 for that next layer. For example, asshown in FIG. 13, the MAC Protocol Data Unit (MPDU) 601 c may become thePHY Service Data Unit (PSDU) 602 d.

As shown in FIG. 13, the APP layer may add a simple header 603 that mayinclude information about packet length and packet type to any packet600 that is sent. The NET layer may add its header 604 to the packetsent down by the APP layer. The MAC layer may add a header 605 a andfooter 605 b to the NET layer packet, and the PHY layer may add a header606 to the MAC layer packet. The actual packet that is transmitted maybe the PHY packet 607.

When the packet 607 is received, each layer may remove its header (andfooter, if any) and (if necessary) may pass the packet up to the nexthighest layer. This type of operation is typical for layered protocols.

802.15.4 does not address the format of packets in the APP and NETlayers; thus, a WSN 100 may use its own format. The WSN 100 MAC header605 a may be 802.15.4 compliant.

The WSN 100 PHY header 606 may differ from the 802.15.4 PHY header if analternative radio or frequency hopping is used.

Heartbeats

Each child node may occasionally send a heartbeat to each of itsparents. A parent may respond with an acknowledgement. Thisacknowledgement may include:

-   -   An indication of a Store-and-Forward message (such as a Host 4        or application-level acknowledgement) queued for the child node.        In this case, the child may execute the procedure, defined in        the 802.15.4 MAC, to download the queued store-and-forward        message.    -   If so requested within the heartbeat message, Beacon information        to enable the child to resynchronize to its parent's time base.

The information above may not be part of the 802.15.4 acknowledgementpacket. Implementers may define a non-compliant acknowledgement packetto include efficiently the information above.

All heartbeats may be acknowledged. Lack of an acknowledgement mayindicate to the child node that the heartbeat was not received by itsparent and should be retried.

If a node loses contact with its parent for many consecutive minutes,the relative clocks of the child and parent may drift apart, and thussynchronization may be lost. To retain time synchronization, a periodicparent/child interaction is needed. A heartbeat may not be the mostpower-efficient way for a node to retain time synchronization with itsparent. For example, the child may forecast the timing of the parent'sBeacon and may listen to the channel exactly when the Beacon isexpected. Listening for a Beacon once per minute or so may require (veryroughly) that the receiver run for about 7 milliseconds per minute, at apower cost of about 5 μJ/ms * 7 ms/min * 1440 min/day * 365days/year=1.5E8 μJ/year. This is about 1.5% of the capacity of a pair ofAAA batteries, i.e., not a significant power issue. Using a heartbeatsolely for the purpose of time synchronization, with a power-consumptivetransmission added to the mix, may consume on the order of 5-10 timesmore power (depending on the details of the parent-child interaction).For this reason, it may not be desirable to use a heartbeat for timesynchronization unless the application has a separate requirement forfrequent heartbeats.

On the other hand, if a child node has an application requirement forfrequent heartbeats with acknowledgements, time synchronization may comemore or less for free by adding the time base to such acknowledgementpackets.

Some channels may have consistently better connectivity than others. Iflocal regulations permit, it may be a desirable optimization to timeheartbeats and other periodic parent-child interactions to coincide withhops that utilize such channels. Depending on implementation details,local regulations may require unbiased use of all available channels; aconfiguration option may be provided to cover such situations.

When a node is first registered as a Router's child, the Router 2 maycommand the child to send a heartbeat to the Router 2 periodically, witha default interval defined by the Router 2. The Router-defined heartbeatrate may typically be relatively slow, such as every 15 minutes. Theprimary purpose for this Router-requested heartbeat may be to confirmthat the child is still alive so that Router resources to service thatchild may remain on reserve. If the Router 2 does not receive aheartbeat from the child during this default period, it may inform theHost 4 of this fact. Additionally, the Router 2 may drop a non-reportingchild from its list of children (informing the Host 4 of this action) iflimited resources so require.

Likewise, such a heartbeat may periodically confirm to the Host 4application that a node is still operating. The Host 4 application mayinfer the node's good health by a lack of exception reports from thenode's primary parent.

For some applications, the node may add an additional heartbeat asrequired by the application. Some examples include:

-   -   Actuators. Heartbeats may be used to poll a node's parent for        pending store-and-forward messages. Actuation commands may be        one important type of message. Actuators may need to communicate        with the parent frequently enough to meet the application's        performance goals. For example, if the user requires a sprinkler        head to respond within 5 seconds, sprinkler-head Star nodes 1        may utilize a 2-3 second heartbeat to poll for such commands.        Alternatively, if the actuator is powered, the Star node's radio        receiver may run continuously (or for the duration of the        parent's CAP 402). Actuation messages may then be sent        immediately to the Star node 1 when received by its parent.    -   Security applications. Nodes used for security applications may        periodically send heartbeat messages as indicators that the node        is still working and no one has tampered with it.

If an application requires a frequent heartbeat, it may do so throughits primary parent. For example, there may be a one-minute heartbeat toa node's primary parent and a fifteen-minute heartbeat to a node'ssecondary parent. A timeout of the one-minute heartbeat to the primaryparent may indicate an alarm condition that is interesting to the userand may be reported by the network as such. A timeout of thefifteen-minute heartbeat to the secondary parent indicates only thehealth of the link.

As noted above, either the parent or the child may set the child'sheartbeat rate. In either case, a missing heartbeat may be reported tothe Host 4 by exception.

A child node may attempt to ensure that its parent receives eachheartbeat on time. A few seconds before its parent is expecting aheartbeat, the child may initiate the following sequence:

-   -   8. The child may send a heartbeat packet addressed to its        primary parent. If all goes well, the packet is acknowledged and        the child may go back to sleep.    -   9. If the heartbeat is not acknowledged, the child may retry the        heartbeat on other available frequencies (such as one try per        channel in an AFA or FH system). If possible, the child may        allow a few seconds to elapse so that temporary situations (such        as moving objects getting in the way) may resolve themselves.    -   10. If the heartbeat is still not acknowledged, the child may        try to send an “I'm alive” message to the Host 4. The normal        approach may attempt to utilize the primary and secondary        parents, so if either link is operational, this should work.    -   11. Having done its best to send a heartbeat, the child may go        back to sleep and may try to send the heartbeat again at the        next interval. If the previous heartbeat failed and the        heartbeat interval is long, the child may shorten the interval        and/or retry several times during the interval.    -   12. The child's application may include logic to search        periodically for a new network in the event that connectivity is        lost.

If a parent receives a heartbeat after it reports that the heartbeat wasmissed, it may immediately report to the Host 4 that the child hasre-appeared.

If a parent receives any message at all from a child during a period, itmay assume that the child is still alive and not report an exception tothe Host 4.

Routers 2 may also generate heartbeats directed to their parents and mayoperate similarly to the child node operation described above.

Store-and-Forward Messages

As noted above, heartbeats may be used to trigger the transmission ofstore-and-forward messages from a parent to its child.

The store-and-forward option may not always be used. Messages betweenRouters 2 may be transmitted without a trigger if a downstream Router 2is expected to be awake, such as during a CAP 402. Similarly, if a Starnode 1 is powered and generally awake, messages may be sent to such Starnodes 1 without waiting for a heartbeat or poll.

Due to the possibility that a node may receive its message from eitherits primary or secondary parent, each parent may maintain one or morepacket buffers for each child for which the parent is responsible. Thisbuffer may contain the most recent packet destined for each child. Thenext packet destined for that child may overwrite the currently occupiedmemory. This method may allow a child to receive the data from either ofits parents, and the acknowledgement mechanism may handle thesingle-threaded nature of the buffer.

Each packet may have a marker of its importance that may indicatenecessary data (high priority data) vs. disposable data (data that isless important to reach the child node). If a new message arrives for achild, but the parent is still holding a packet in the buffer for thatchild, the parent may look at the importance marker for the held packet.If the held packet contains disposable data, the parent may overwritethe held packet with the new packet. However, if the held packetcontains necessary data, the parent may reply to the sender that it isstill holding a necessary packet for that child. If the child hasalready received that necessary packet via an alternate route and hassent an acknowledgement to the Host 4, the Host 4 may send an overridecommand to the parent telling it to overwrite the held packet with thenew packet. In another embodiment, a parent may maintain a hash table tohold messages for forwarding.

In another mode or embodiment, the parent may indicate in its FrameBeacon 401 that certain children need to pick up store-and-forwardmessages. If such Beacons are precisely timed, a child node may monitorthe channel at exactly those times without a substantial power impact.This approach may also limit the amount of radio traffic that mightotherwise be generated by children polling for messages. If a largenumber of children have pending messages, a flag in the Frame Beacon 401may indicate that each node or certain groups of nodes need to poll theparent for messages.

A parent may also keep a table of its child nodes. The table mayinclude:

-   -   the short ID for each child    -   the child's relationship to the parent (e.g., whether the Router        2 is a primary or secondary parent to that child)    -   whether there are any pending store-and-forward messages for the        child    -   other information, such as when the child was last heard from        and heartbeat rate

If a child has not been heard from recently (i.e., it has sent neitherheartbeats nor messages for a certain length of time), its primaryparent may send a “lost node” message to the Host 4. If the Host 4 isaware that the node has rejoined the network with new parents, thenode's original parents may be instructed by the Host 4 to drop allpending messages for that node. If the node is entirely lost, it maysimply be dropped from the network.

If a Router 2 is lost, all nodes below that Router 2 may also be lost.Thus, the Host 4 may instruct the Router's parent nodes to drop allmessages with the lost Router 2 in their destination path.

Sending Messages from a Child Node to a Host

When a Child node has a message to send to a Host 4, a flag in themessage may indicate that a particular Host 4 is the destination.Delivery to the Host 4 may not be guaranteed. The Child node may requesta Host acknowledgement as confirmation that the message was actuallyreceived.

An illustrative send/retry strategy is illustrated in FIG. 14. As shownin FIG. 14, when the Child node sends a message, the Child node may gothrough the following steps:

-   -   1. Determine whether there is a message to send (S41). If not,        go to sleep (S42).    -   2. Determine whether the message is urgent (time-critical)        (S43).    -   3. Attempt to send the message to the Child node's primary        parent (S44/S45). If the primary parent acknowledges receipt of        this message, the Child node may skip to Step 7.        -   3a. If the message is urgent, send the message using the            next available channel (S45).        -   3b. If the message is not urgent, send the message using the            preferred channel (S44). As noted earlier, the preferred            channel may be selected by testing the quality of available            connections or by using the most recent channel that worked.    -   4. If the time slot has not terminated, retransmit the message        to the primary Router 2 (S46/S48). This may allow an inadvertent        collision or other transient connectivity problem to resolve        itself. If the primary Router 2 acknowledges the packet, proceed        to step 7.        -   4a. If the message is urgent, send the message using the            next available channel (S48).        -   4b. If the message is not urgent, send the message using the            preferred channel (S46).    -   5. Attempt to send the message to the Child node's secondary        parent Router 2 (S49/S50). If the secondary Router 2        acknowledges receipt of this message, the Child node may skip to        Step 7.    -   5a. If the message is urgent, send the message using the next        available channel (S50).    -   5b. If the message is not urgent, send the message using the        preferred channel (S49).    -   6. Try sending to primary/secondary Router 2 on another        available channel (S52). (In an FH system, wait until the        network hops to a frequency that is separated from the frequency        used in Steps 1a & 1b by at least 5 MHz. It is preferable to        design hopping sequences so that all hops exceed 5 MHz.)    -   7. Repeat Steps 1-6 (S41-S52) a number of times that is defined        by the application. Two or three tries may be reasonable for        most applications.    -   8. If a node requests an acknowledgement from the Host 4, the        node may generate a heartbeat at an application-defined rate for        an application-defined amount of time (S53). In an application        in which messages are supposed to be received by the Host 4        within 5 seconds, for example, it may be reasonable to generate        a heartbeat every 2 seconds (±a randomized factor) for 10        seconds before timing out. This heartbeat may be addressed to        the node's primary or secondary parent, depending on which        parent gave a positive acknowledgement in earlier steps. The        heartbeat (as described above) may allow the node to receive a        store-and-forward acknowledgement from the Host 4.    -   9. If a Host acknowledgement was requested by the application,        the network layer may ultimately call back with either a Host        acknowledgement (in which case the node may go to sleep (S56))        or a timeout (S55).

Routers 2 may also have primary and secondary parents and may useessentially the same procedure as above to forward messages from Router2 to Router 2 back towards the Host 4. Each node may attempt to forwarda message to its own primary (or secondary, if necessary) parent, whichmay in turn forward the message to its primary (or secondary, ifnecessary) parent, and so on, until the message reaches the Host 4.

The originating Child nodes may classify messages as low priority orhigh priority. High priority messages may be forwarded to the Host 4 asquickly as possible. In contrast, Routers 2 may combine low-prioritymessages into fewer but larger consolidated packets to reduce networktraffic. (In high traffic scenarios, consolidated packets may be used onhigh priority messages as well, with the intent of reducing the averagelatency of high priority messages.)

A Router 2 sending messages to a Host 4 on its own behalf may act as aChild node in that context.

Sending Messages from the Host to a Star Node, and from One Star Node toAnother

Messages from the Host 4 to a Star node 1 may have a two-part address: a16-bit Router ID and the Star node's ID. Normally, a message may beaddressed to the Star node's primary Router 2, with three exceptions:

-   -   13. The Host 4 is responding to a message or command that was        sent through the Star node's secondary Router 2;    -   14. Connectivity to the primary Router 2 is poor.    -   15. The message is addressed to a Router 2, not a Star node 1.

Messages may be sent from Host 4 to Star node 1 in essentially the sameway as messages are sent in the other direction, with routing asillustrated in FIG. 12. Messages from Star node 1 to Star node 1 mayalso be supported as illustrated in FIG. 12.

In one embodiment, messages from one node to another may not need topass through the Host 4. Once routing tables have been built, Routers 2may have established routes for all Routers 2 below them (i.e., theirchildren, and their children's children, etc.) Thus, a message from onenode to another may be sent upward to a common ancestor. Once themessage reaches a common ancestor, the common ancestor may recognizethat the message is intended for one of its subordinate nodes. Thecommon ancestor can then forward the message to one of its children,where the message can be forwarded as needed to the intended recipient.An example is shown in FIG. 15.

In FIG. 15, Star node 1 a (A) wants to send a message to Star node 1 b(B). A sends the message, addressed to 2,B, to its primary parent Router2 b (1). Router 2 b (1) does not know 2,B, so it forwards the message toits primary parent Router 2 a (3). Router 2 a (3) knows Router 2 c (2),so it sends the message down to Router 2 c (2), and Router 2 c (2)forwards the message to 2,B (when Star node 1 b (B) is awake).

If no node along the forwarding path knows a route for the designatedrecipient node, the message may be forwarded all the way to the Host 4.

Addresses may be established for additional devices. For example, adatalogger may be established at an address, and packets sent to thataddress may be logged by the datalogger.

Broadcast Functionality; Reprogramming the Nodes

Large messages several kilobytes long may occasionally need to besimultaneously broadcast to a large number of nodes. An application ofthis kind may be wireless reprogramming of the nodes.

A Router 2 wishing to broadcast a long message may break the messageinto small sections, such as 64 bytes long. Each section may benumbered, thus enabling the recipient to assemble the message even if itis received out of order. The Router 2 may then fix a schedule tobroadcast one section every a±b seconds. One option is to broadcast theone or several consecutive fragments just before the normally scheduledtimes for the Frame Beacons 401, which would have the effect ofshortening the maximum length of the prior CAP 402 by a correspondingnumber of milliseconds. In response to heartbeats from its child nodesand/or in Frame Beacons 401, a parent node may announce that atransmission with a given sequence number is in process. The fragmentedmessage may be transmitted some number of times, with fragmentstransmitted in a preset order, as requested by the Host 4. For asoftware download, three transmissions may be an appropriate number.

A node may learn about message broadcasts in a heartbeat acknowledgementand/or in Frame Beacons 401. The node may then issue a query to theRouter 2 to learn more about the message, such as message number andtransmission schedule. The node may then use one of the followingtechniques to decide whether the message is directed at the node:

-   -   The node application may query the Host 4 regarding whether the        numbered transmission is of interest and, if so, what to do with        it.    -   The message may be directed at a group number. If the node has        the same group number, it may process the message as per cached        instructions provided by the Router 2.    -   The message may be directed at a range of firmware version        numbers. If the node's firmware is in that range, the message        may be treated as a firmware update.

The node may assemble the message by synchronizing itself with theRouter's message transmission schedule and placing the numbered sectionsinto a buffer. Since sections may be transmitted in order, the node mayknow when given sections will be transmitted. As sections are filled in,the node may not need to waste power reading those sections again.

The node may listen to its primary and secondary Routers 2simultaneously to receive the message more quickly and reliably.

When the Routers 2 are done transmitting the message, some nodes mayhave sections that are missing. A special transaction may allow a nodeto request transmission of specific sections to fill in the blanks.

Each packet that is sent across the communications link may be CRCchecked according to the ITU-CRC-16 methodology. According to ComputerNetworks (Andrew S. Tanenbaum, 2002, Pearson Education), the accuracy ofthis check is at or near 100% for various types of errors, includingsingle bit and double bit errors (100%), odd-numbered errors (100%), andburst errors (100% when shorter than 16 bits; 99.9969 % when exactly 17bits, 99.9984 % for other burst errors). The error detection efficiencyof CRC-16 may virtually eliminate errors, as it is considered nearlyflawless for packets less than 4 Kb. As an additional check further toensure reliability, a CRC may be calculated for each block of 1024 bytesthat is transmitted for the purpose of code upgrade.

The bit error rate of the radio may make it more efficient to sendrelatively long message segments with forward error correction.

Each node may confirm to the Host 4 when its software download iscomplete. At this point, the Host 4 may issue a packet to the node totell it to reboot and to utilize the new code.

Despite the best efforts of the data transmission code, the image may becorrupted. This problem may be solved by the utilization of a smallbootstrapper, which may be loaded into the device to serve two purposes:to reduce the active code space utilized during the download process,and to allow the device to reset to the bootstrapper in the event thatthe code that was downloaded is corrupted or unable to execute.

The bootstrapper may be capable of running the radio for the purpose ofdownloading code and of managing the images to assure that they runproperly.

Network Topology Changes

In the following sections, we discuss changes in topology in a WSN 100.We focus here on AFA systems; modifications that may be required for FHsystems are also discussed. In the following discussion, we describecertain illustrative embodiments; however, these descriptions are purelyillustrative and are not intended to be limiting.

In the normal course of network processing, a device may lose contactwith its primary or secondary Router 2, or other conditions may occurthat require changes to be made to an existing network. Four generalcases in which changes to an existing network may be required aredescribed below.

Star Node Loses Connectivity to Parent Router

First, there is the case of a Star node 1 that is experiencing problemswith connectivity to its primary or secondary Router 2. In this case,the Star node 1 may need to search for a new set of parents.

To conserve power and bandwidth, a Star node 1 may not search for a newsecondary parent if its secondary parent is lost but its primary parentremains accessible. Also, if a primary parent is lost but a secondaryparent remains viable, a Star node 1 may not immediately seek a newprimary parent. The amount of time for which a Star node 1 may functionwith only a secondary parent and no primary parent may be configurable.An exception to this procedure may be if a parent is lost but the Starnode 1 had a packet addressed to that parent (as opposed to a packetthat is simply being routed through that parent). In this case, the Starnode 1 may seek new parent Routers 2.

One way for the Star node 1 to reacquire the network may be for the Starnode 1 to wait on a channel until it sees a Beacon from at least oneRouter 2. The Star node 1 may request that the Router 2 ping the Starnode 1 on each frequency for a full Sequence cycle, so that connectivitymay be assessed. Although the Star node 1 may request a ping on eachfrequency (i.e., “Ping me.” <next frequency> “Ping me.” <next frequency>“Ping me.” and so forth), this may create unnecessary network traffic.Instead, the Star node 1 may request the pings all at once, i.e., “Pingme once per frequency for a full cycle.”

In another embodiment, rather than pinging only that Star node 1, theRouter 2 that is being considered may broadcast a message on eachfrequency for a full cycle of hops. This may allow all Star nodes 1 thatare evaluating that Router 2 to use the same message, rather than eachStar node 1 requesting and receiving separate pings. This may be usefulif multiple Star nodes 1 have lost contact with their parents.

When ping data has been received and an assessment completed, the Starnode 1 may autonomously choose new parents. Alternatively, the Star node1 may forward connectivity data to the Host 4 and the Host 4 may assignnew parents to the Star node 1. The Star node 1 may then notify its newparents of their assignment.

Routers 2 may lack the global information to reconfigure themselvesoptimally. In contrast, Star nodes 1 may autonomously move from oneRouter 2 to another without affecting the rest of the network. Theprimary tradeoff is that it requires battery power to assessconnectivity to alternative Routers 2. Since connectivity data may shiftas conditions change, but moving to a new Router 2 may require batterypower, it may be desirable to set a range within which a Star node 1will not attempt to switch Routers. For example, a Star node 1 may notattempt to move to a new Router 2 unless the connectivity assessmentchanges by a certain amount for a certain length of time, which mayindicate that the connection to a Router 2 has gotten significantlyworse and that this is a lasting condition rather than a momentaryanomaly. This may help to reduce power consumption.

Care should be taken in implementation to avoid scenarios where the Starnode 1 wastes power and bandwidth flip-flopping between connections ofsimilar quality. This might be avoided by keeping a record of recentchanges.

When a Star node 1 changes its connection, it may inform the Host 4 thatit has moved from one Router 2 to another.

Although Star nodes 1 can determine which Routers 2 have the bestconnectivity, it may be better for the network if the Host 4 decideswhich Star node 1 is associated with which Router 2. For applicationswhere Star nodes 1 are largely stationary, in the typical case Starnodes 1 should not change Routers 2 unless connectivity is lost. Ifconnectivity remains reasonable, a Star node 1 should only changeRouters 2 if requested to do so by the Host 4. The Host 4 may maintainadditional information that can help load balance the network. It mayalso allow Star nodes 1 to be associated in a fashion that can indicatetheir physical proximity.

If connectivity falls below a preset threshold (e.g., probability<0.33), the Star node 1 may inform the Host 4 that it has a problem andgo to sleep. It may heartbeat at a low rate in case the system'soriginal configuration is re-established. If many consecutive heartbeatsfail (e.g., 20), the Star node 1 may also stop transmitting theheartbeat. Note that if connectivity is lost completely for an extendedperiod, time synchronization may be lost.

In the event that connectivity is lost, a Star node 1 may periodicallyattempt to rejoin the network, starting with acquiring the system's timebase. One way for the Star node 1 to reacquire the network may be forthe Star node 1 to wait on a control channel until it sees a FrameBeacon 401 from at least one Router 2. Then the Star node 1 can completea new connectivity assessment. When the assessment has been completed,the Star node 1 may autonomously choose new parents and preferredcommunication channels. Alternatively, the Star node 1 may forwardconnectivity data to the Host 4 and the Host 4 may assign new parents tothe Star node 1. The Star node 1 may then notify its new parents oftheir assignment.

A Star node 1 may periodically receive a command from the Host 4 of theform “reconfigure at a randomly selected time in the next x minutes.” Ifx is zero, the process should proceed immediately.

There may be some applications where a Star node 1 may move periodicallyor even relatively continuously. If a Star node 1 is expected to bemobile, such as a Star node 1 with a motion detector on an asset, then aconnectivity problem combined with detection of motion may be evidencethat a Star node 1 may need to seek new parents. This situation, alongwith other cases, is discussed subsequently.

If a child Star node 1 times out, its parent Routers 2 may drop the Starnode 1 and inform the Routers' parents. Eventually, this information mayreach the Host 4 and routing tables may be changed accordingly.

Host Decides to Rebuild Network

Second, there is the case in which the Host 4 may periodically decidethat the network should be rebuilt. For example, the Host 4 may receiveinformation that indicates numerous connectivity failures in thenetwork. In this case, the Host 4 may discard existing routing tablesand may allow all remaining Star nodes 1 and Routers 2 on the network totime out. The Host 4 may increment the session ID by one. The networkmay then be rebuilt as if it were a new network (as described earlier)using a new session ID. When a new network is built using a new sessionID, all activity using the previous session ID may time out.

It may be desirable to reconfigure the network periodically even in theabsence of connectivity failures. Connectivity assessments may beconducted continually using heartbeats from Star nodes 1 and Routers 2(as described earlier in the section concerning system communications),Beacons, or acknowledgements. For example, a Star node 1 may keep trackof who it heard from and at what times. This data may be used tocalculate the percentage of packets received by that Star node 1 fromeach Router 2. If dramatic (i.e., above a certain threshold) changes aredetected, the Host 4 may choose to allow all Star nodes 1 and Routers 2to time out, and then the Host 4 may reform the network.

The Host 4 may instead instruct a Star node 1 or Router 2 to reacquirethe network. A Star node 1 or Router 2 may receive a command from theHost 4 of the form “reconfigure at a randomly selected time in the nextx minutes.” If x is zero, the reconfiguration process may proceedimmediately.

When a Router 2 reconfigures, all routing tables may be deleted so thatold paths containing that Router 2 are not kept in the routing tables.

Router Loses Network Connectivity

Third, there is the case in which a Router 2 is lost vis-á-vis thenetwork. An example is shown in FIG. 16.

Referring to FIG. 16, if connectivity to Router 2 d (D) is lost, thenRouter 2 f (F) might switch to Router 2 b (B) as its primary and Router2 e (E) as its secondary. When a Router 2 is lost, all routing tablesmay be updated so that old paths containing that Router 2 are not keptin the routing tables. If a child Router 2 times out, its parent Routers2 may drop the child Router 2 and its descendents and may inform theparent Routers' parents. Eventually, this information may reach the Host4 and routing tables may be changed accordingly.

If 2 f is not a Router but a Star node 1, then it may seek new parentsas described in the first case (of a Star node 1 losing connectivity).However, as noted earlier, Routers 2 may lack the global information toreconfigure themselves without causing problems. In the case shown, evenif 2 f (F) is a Router 2, F does not have any Routers 2 as children, andit can reconfigure itself without danger of creating circularreferences.

However, if a Router 2 is in the middle of a tree, such as Router 2 b(B), it might create circular paths if it chooses new parentsindependently. Such Routers 2 may notify the Host 4 that connectivityhas been lost and may await farther instructions from the Host 4. TheHost 4 may assign new parents to the Router 2 based on connectivityassessments. Routers 2 may also have instructions not to become childrenof their own dependents to prevent circularity.

When Router 2 f (F) notices that its primary parent Router 2 d (D) hasbeen lost, Router 2 f (F) may notify the Host 4 to drop existing pathsutilizing the lost Router 2 d (D). This notification may contain asession ID or time stamp so that the Host 4 may determine the order inwhich packets were sent. The Host 4 may then drop existing routing tableentries using the lost Router 2 d. The Host 4 may instruct all Starnodes 1 and Routers 2 that previously were Router 2 d (D)'s children toperform connectivity assessments for assigning new primary and secondaryparents to those children.

Another way to update routing tables when a Router 2 is lost may be foreach Router 2 to examine “lost node” messages that are sent upwardtoward the Host 4 and, if a Router 2 is reported lost, drop all pathscontaining the lost Router 2. In this case, total path weights may needto be recalculated to determine the new lowest path weight and thus thenew preferred route for each of the lost Router's subordinate Routers 2.

If the lost Router 2 d is still “alive” (though not communicating withthe rest of the network), it may dissociate itself from its children.The children may then discover that they can no longer communicate withtheir parent and thus may need to seek new parents.

If Router 2 d (D) is later able to reestablish connectivity, it mayrejoin the network as a new device. However, it may not rejoin in itsoriginal position, as the Host 4 may choose to realign the network basedon current connectivity assessments. (Based on connectivity data,however, the Host 4 may indeed choose to place Router 2 d (D) back intoits original position.)

Other Changes in Topology

Fourth, topology changes may be made outside of the constraints coveredby the three cases previously described. Topology changes may requirethat as few Routers 2 as possible update their routing tables. Allrouting tables that involve the affected part of the network may berecreated. This process may not require that any devices be orphaned.The devices may simply destroy their routing tables and recreate them asdescribed earlier. Most nodes, except for those that have lost a parent,may not even be aware of the changes. When routing tables are changed, anew session ID may be assigned by the Host 4.

Instead of recreating the routing tables, the network may be terminatedby changing the Session ID. In an FH system, this may be accompanied bya change to the FH Sequence. If the network is terminated, it may needto reform as described below.

Devices that know the topology has changed may generate new routinginformation for the new topology and may send this up to the next Router2 as they would in network formation. Each device that receives a newentry for a device may replace the previous data for that device. Theremay be no comparison of existing routing information with the newinformation, because the old routing information may have becomeinvalid.

The routing table may require that an identifier be associated with therouting information to assure that data is not erroneously deleted. Whena device changes the information describing a particular path, it maychange the identifier associated with the information. Only the pathsthat are modified may require the updated identifier. This way, a devicethat receives updated data may discern between updated information anddata that need not be modified.

Once a Router 2 joins the network, it may lack a total picture of thenetwork, and, without such knowledge, “localized” changes in the networkhierarchy may result in circular paths. As noted earlier, Routers 2 mayhave instructions not to become children of their dependents to preventcircularity. Alternatively, a reconfiguration scheme may be developedthat does not involve the Host 4, for example borrowing from literatureon Destination Sequence Distance Vector (DSDV) routing. However, it maybe more efficient and give better results to model and define networktopology changes on the Host 4.

Routers 2 may need to support the following functions to enable the Host4 to reconfigure the network:

-   -   Routers 2 may continuously conduct Quick Assessments of        connectivity to nearby Routers 2 and may periodically report        this to the Host 4. This Quick Assessment may be robust enough        to detect when new Routers 2 have joined the network. (If the        Router 2 is on a duty cycle, Quick Assessments may instead be        done periodically or only on request from the Host 4.)    -   The Host 4 may request that a Router 2 report its most recent        Quick Assessment data.    -   The Host 4 may request that a Router 2 conduct a Detailed        Assessment with respect to one or more of its neighbors.    -   The Host 4 may request that a Router 2 or Star node 1 change its        primary and/or secondary parents and may receive confirmation        that this has been accomplished.

Such changes may involve routing changes in both directions. It may bethe Host's responsibility to serialize such requests across the networkso that network integrity is not lost at any step.

Under this design, a new Router 2 may join an existing network, butexisting Routers 2 may not be routed through this new Router 2 unlesscommanded by the Host 4 to do so, or unless the network is rebuiltstarting from the Gateway 3.

Addressing Packets in Transmission during Network Reconfiguration

When connectivity is lost for a Star node 1 or Router 2, there may bepackets in transmission to or from that Star node 1 or Router 2.However, it may be desirable to ensure that packets are not lost intransmission. How this is addressed may depend on where the packet iswhen connectivity is lost.

If a packet is being sent from the Host 4 to a Star node 1 via itsprimary parent, but connectivity to that primary parent is lost whilethe packet is in transmission, the packet may not reach the Star node 1,and the Star node 1 may not send an application level acknowledgement tothe Host 4. The last Router 2 that handled the packet may note theabsence of a MAC level acknowledgement and may interpret such an eventas a failed transmission. The Router 2 may attempt to resend the packetto the Star node 1 via its secondary parent. If this also fails toresult in an acknowledgement, the Router 2 may attempt to resend thepacket via another path. If no acknowledgement is received, eventuallythe Router 2 may notify the Host 4 that connectivity to the Star node 1may be lost.

If a packet has been sent to a Star node 1, and the Star node 1 hasreceived the packet, the Star node 1 may send an acknowledgement to theHost 4. However, if a Router 2 on the path from the Star node 1 to theHost 4 loses connectivity while the acknowledgement is being sent, theHost 4 may not receive the acknowledgement. (For example, in FIG. 12, ifan acknowledgement is being sent from Router 2 f (F) to the Host 4, andRouter 2 b (B) is lost while the acknowledgment is in transmission, theacknowledgment may not reach the Host 4.) The Host 4 may attempt toresend the original packet and may attempt to send the original packetusing a different path or by flooding, until it receives anacknowledgement from the Star node 1 that the packet was received.

If a Star node 1 sends a packet to the Host 4, it may expect anacknowledgement within a certain time, depending on the hop count andtypical latencies between the Star node 1 and the Host 4. If noacknowledgement is received within the expected time, the Star node 1may attempt to resend the packet and may attempt to utilize a differenttransmission path.

If connectivity is reestablished while packets are being retransmitted,this may result in the same packet being received more than once. Thismay increase network traffic but may ensure that all packets arereceived and acknowledged.

Support for Multiple Gateways

The specification thus far has been mostly limited to WSNs with singleGateways 3. For a single Gateway 3 configuration, the system may build asingle tree of primary connections feeding back to a common Gateway 3,with secondary connections that may provide backup paths to the sameGateway 3. This paradigm may be generalized to support multiple Gateways3, as shown in FIG. 2. As shown in FIG. 2, Gateways 3 a (X), 3 b (Y),and 3 c (Z) are connected to a common Ethernet backbone. Routers 2 a-lmay form connections to those Gateways 3 a-c as described previously.One important advantage of a multi-Gateway configuration is that thesecondary path may lead to a different Gateway 3 than the primary path.For example, in FIG. 2, Router 2 h (H) has a primary path to Gateway 3 bY and a secondary path to Gateway 3 c (Z). In fact, in the configurationshown in FIG. 2, the failure of any single Gateway 3 a-c or Router 2 a-lmay be tolerated. Another advantage of a multi-Gateway 3 configurationis that the number of hops to a Gateway 3 may be reduced when Gateways 3are interspersed among Routers 2, resulting in a faster and morereliable network.

As drawn, the routing shown in FIG. 2 implies that it does not matterwhich Gateway 3 a-c is used for communication with a particular Starnode 1 a-t or Router 2 a-1. Thus, the one “single point of failure” inthis picture is the backbone itself, shown as an Ethernet 50 in FIG. 2.The routing topology may be configured to support a parallel collectionof Gateways 3 on separate networks, with routing tables configured toprovide every node with connectivity to each Gateway 3. Alternatively,in typical applications redundant backbones may not be necessary. Thereare various solutions to provide reliable Ethernet and similar backboneswith different cost/reliability tradeoffs as appropriate for specificapplications. In contrast, individual WSN components are generally basedon very inexpensive radios and related components optimized for lowcost. It may therefore be reasonable to design a WSN 100 under theassumption that any specific WSN link or device is intrinsically lessreliable than the backbone connecting Gateways 3.

The potential configurations with multiple Gateways 3 may grow morecomplicated as the WSN 100 scales. As a WSN 100 grows to includepotentially dozens of Gateways 3, individual Routers 2 may simply nothave the network-wide information to derive optimal Router topology.Additionally, the Routers 2 may not necessarily have the processingpower to make sophisticated network tradeoffs; in fact, it may bedesirable to conduct such processing elsewhere if it will reduce Routerprocessing/storage requirements and thence Router costs. Furthermore,the programming environments in Routers 2 may make it difficult to writecomplex software to make subtle network-wide topology tradeoffs. Withtoday's microprocessors, a Gateway 3 may plausibly be designed around a$25 processor running Linux, with many megabytes of storage tofacilitate network operation. Such Linux-based Gateways 3 may provide abackbone of “network brains” that are relatively easy to program. Itthus may make economic and practical sense for network intelligence tobe placed in Gateways 3 as WSNs scale.

As the Gateways 3 grow more sophisticated, Routers 2 may be simplifiedmerely to follow configuration commands issued by intelligent Gateways3. The following set of capabilities represents a minimal set offunctions that may be needed by such Routers 2:

-   -   Join the network. Follow the procedure used by Star Nodes        (described previously) to join the network.    -   Conduct connectivity assessment and report results.        Spontaneously and/or in response to Gateway commands, conduct        Connectivity Assessment to Routers 2 in range and report        results.    -   Modify primary an(a/or secondary parents. In response to a        command, change position in the network and confirm the change.        The change may be implemented by the node in two steps by first        removing itself from its current parent(s) and then adding        itself to its new parent(s).    -   Convert between Router and Generic node. A Router 2 may need to        act temporarily as a Generic node during periods when the        network is being formed and reconfigured. For example, a new        Router 2 joining the network may first join as a generic device,        then have its parents chosen through Gateway commands, and then        become a Router 2 (or Star node 1) through another command from        the Gateway 3.

With these four baseline commands in place, Gateways 3 have the tools toanalyze network connectivity and configure network topology as needed.Simultaneously, Routers 2 may be simplified by letting the Gateways 3handle subtle routing decisions.

As described earlier, connectivity assessments may be chained toestimate the likelihood that a packet sent by one device will reach anyother device in the network. FIG. 17 provides an example withConnectivity Assessments in a WSN 100 with two Gateways, 3 a (A) and 3 b(A′). For example, the probability that a packet sent by Router 2 f (F)will reach the Host 4 is 90% * 80% * 80%=58% if the path F-D-C-A-Host isused and 90% * 80% * 90%=65% if the path F-D-C-A′-Host is used.

Enhancements to the WSN Architecture

The following sections describe some enhancements that may be used witha WSN architecture.

Supporting Multiple Networks in Range

Although much of our earlier discussion described a system with only onenetwork in range, the WSN architecture may be used with multiplenetworks in reasonably close proximity. The networking software mayinclude a “group number” of some kind to ensure that a Star node 1 doesnot join the “wrong” network. In absence of such a group number, a Starnode 1 may join whichever network has the best connection. Transactionsmay be provided whereby a Host 4 tells a Star node 1 to find anothernetwork.

Another possibility is that unique IDs may be associated with a device,and a list may be created that allows only devices with known IDs to beadded to a network.

Support for Star Nodes in Motion

Star nodes 1 that move frequently, such as Star nodes 1 integrated withhandheld computers, may continually need to connect to different Routers2. The process of continuously joining and re-joining may use systembandwidth and power. Some kind of specialty protocol may be needed forsuch Star nodes 1, presuming that they are the exception rather than therule. One approach is for such Star nodes 1 to listen periodically forBeacons from nearby Routers 2 and then direct traffic through nearbyRouters v (without actually becoming children of such Routers 2) on anas-needed basis.

Support for Routers in Motion

Our earlier discussion uses examples in which connections betweenRouters 2 remain relatively stable over time. The system may use an apriori strategy, taking pains to characterize these connections tocreate an optimal path. For applications where Routers 2 are not infixed positions, the careful characterization described herein may be aninappropriate use of bandwidth, time, and power. An on-demand approach,such as flooding or Ad Hoc On-Demand Distance Vector (AODV), may createa more appropriate Router 2 backbone under such circumstances.

WSN System Structure

FIG. 18 illustrates one embodiment of the WSN architecture.

Nodes (which may be Star nodes or Routers, but which are shown as Starnodes 1 in FIG. 18 for simplicity) may connect to Routers 2 inparent-child relationships. Routers 2 may also become children of otherRouters 2. The mesh of Nodes 1 and Routers 2 may connect to a networkbase station 701, which may incorporate proxy and other functions. Fromthe base station 701, Node 1 and Router 2 data may pass via an API 702 athrough an Internet or Intranet connection 703 to other networkeddevices. For example, data may pass to an Ethernet-connected workstation706 via an API 702 d, to a server 704, and/or to a database 705 via anAPI 702 c.

Alternately, Nodes 1 may connect to a handheld computer 707 via an API702 b. If the handheld computer 707 has a network connection, then fromthe handheld computer 707, data may pass to networked devices asdescribed above.

FIG. 19 illustrates one way to structure a WSN 100. PHY 802, MAC 803,NET 804, and APP 805 layers may be present in each wireless node (Starnode 1 or Router 2).

A Gateway 3 may perform protocol conversions. For example, a WSN 100 mayinclude multiple types of wireless nodes from several differentmanufacturers. As it passes through the Gateway 3, the information fromeach of these node types may be converted to a common protocol 806.

There may be an embedded controller 801 with a wireless network proxy,server, and database 807, wireless network applications 808, and an APImodule 809. If more than one protocol is used in the WSN I 00, thenduplicate embedded controllers 801 may be used, one for each protocol.The proxy may be used to process read (e.g., “What is the status of NodeA?”) and write (e.g., “Turn on the actuator on Node B.”) requests.Rather than sending these requests directly from one node to another,network applications 808 may use the proxy to process and forward theserequests, as the proxy's database may maintain the current status of allnodes in the network.

There may also be end user applications 810, such as management softwareand specific user applications (for example, a graphical interface forviewing the status of nodes in the network and data obtained from thosenodes).

FIG. 20 illustrates one embodiment of a WSN controller. Sensor data maybe passed to the controller directly from a WSN 100 through a Gateway 3,or multiple WSNs 100 may form subnets on an Ethernet 50 or WiFi 51 LAN.A protocol server 34 or Gateway 3 may translate data from each differenttype of WSN protocol into a common format. There may be a proxy 32 tohandle read and write requests; the proxy 32 may maintain its owndatabase 35.

From the proxy 32, data may pass to an HTTP server 31, which may forwardthe data to an IP interface 36 in HTTP format; to an OEM programmableinterface 33, which may forward the data to an IP interface 36 in someOEM-selected format; or directly to an IP interface 36. The IP interface36 may transmit the data to an IP network backbone 53 using, forexample, Ethernet 50, WiFi 51, or packet cellular 52. There may also bean RS232 interface 37 for transmitting data through a serial connection,particularly for configuration of the Gateway 3 device.

FIG. 21 illustrates one embodiment of a proxy 32 (VPD, or Virtual ProxyDevice). In the example in FIG. 21, there are four subnetworks: twoSensicast WSNs 100 a and 100 b and two TinyOS networks 100 c and 100 d.Data from each network may pass through a Gateway 3 that may beconnected to a Host 4 via an RS232 connection. Data from each WSN 100may pass through an RS232 Service 901 via TCP to a Protocol Server 902for protocol translation into a format that is common across differenttypes of WSNs 100. From the protocol servers, data may pass to theVirtual Proxy Device (VPD) 32. The VPD 32 provides an abstraction of thenetwork for application programs, whereby each WSN sensor or actuator isrepresented as a software object. The VPD 32 handles the details ofkeeping the virtual devices on the Host 4 consistent with the physicaldevices on the network,.

Within the VPD 32, there may be a VPD Server 905 for processing andforwarding requests and data, and a VPD Data Cache 904 for storinginformation. The VPD 32 may also maintain a database 903. The VPD 32 maybe connected to an administrative graphical user interface (GUI) 906that may be used for network administration; this administrative GUI 906may maintain its own mirror of the VPD Data Cache 904.

The VPD 32 may also pass information to and from specific applicationGUIs. In the example in FIG. 21, there is a Sensor Management System(SMS) GUI 913, which may be used for managing the sensors in the WSNs,and an Object Alarm System (OAS) GUI 914, which may be used to monitoralarm conditions related to sensor data (for example, being alerted whensensors on artwork detect unauthorized touching). The VPD Server 905 maypass information to and from a server specific to each GUI (e.g., an SMSServer 911 and an OAS Server 912) that may forward information to andfrom its own GUI.

Each application-specific server may maintain a mirror of the VPD DataCache 904, as well as its own application-specific data cache 908/909and database 907/910. Each application GUI may itself maintain a mirrorof the VPD Data Cache 904 and of its own application-specific data cache908/909.

In this disclosure, we have described network architectures andprotocols designed for use in wireless sensor networks (WSNs). We haveconsidered adaptive frequency agile (AFA) and frequency hopping (FH)systems within this context. We have discussed network formation,communication within WSNs, system enhancements, and making changes toexisting networks. We have also considered options for security withinsuch networks. Again, the embodiments described herein are meant to beillustrative and are not intended as limiting. Also, various featuresdescribed above may be combined in any suitable way to form a system inaccordance with the invention.

1. A wireless mesh network, comprising: a plurality of star nodesconstructed and arranged to transmit and receive wireless signals; and aplurality of routers each constructed and arranged to transmit andreceive wireless signals for communication with at least one star node,and constructed and arranged to transmit and receive wireless signalsfor communication within at least one other device in the wirelesssensor network; wherein the plurality of star nodes communicates with atleast one router using a plurality of different frequencies, and atleast one router is available for communication with at least one starnode based on a randomized frequency schedule and/or randomized timingschedule that can be forecasted and tracked by other nodes in thenetwork.
 2. The network of claim 1, wherein the at least one router isavailable for communication based on a randomized timing schedule thatis determined using a fixed time interval plus or minus a randomizeddither.
 3. The network of claim 2, wherein the randomized dither isdetermined based on a congruential generator.
 4. The network of claim 2,wherein the randomized dither is determined based on a table that isshared with other nodes in the network and/or calculated using sharedparameters for a shared algorithm.
 5. The network of claim 1, wherein atime period during which the at least one router is available forcommunication at a given frequency is variable in length based on acommunication load for the frequency.
 6. The network of claim 1, whereindevices in the network communication with the at least one router bypreferentially using one or more frequencies at which the devicessuccessfully communicated with the router in the past.
 7. The network ofclaim 1, wherein carrier sense multiple access with collision avoidance(CSMA-CA) is used for communication with the at least one router.
 8. Thenetwork of claim 7, wherein slotted CSMA-CA is used.
 9. The network ofclaim 7, wherein unslotted CSMA-CA is used.
 10. The network of claim 1,wherein each of the plurality of routers is available for communicationbased on a time and frequency schedule that is independent of a schedulefor other routers.
 11. The network of claim 10, wherein each scheduledefines a randomized time and a randomized frequency according to whichthe corresponding router is available for communication.
 12. The networkof claim 1, wherein each of the plurality of routers is available forcommunication based on a schedule that is coordinated with all otherrouters.
 13. The network of claim 15 wherein each of the routerstransmits and receives signals for communication with at least one otherrouter using a plurality of frequencies.
 14. The network of claim 13,wherein the plurality of the routers are each available forcommunication with at least one other router for a period that begins atleast one of at a randomized time or at a randomized frequency.
 15. Thenetwork of claim 1, further comprising at least one gateway, and a hostcomputer, wherein a plurality of routers communicate with the hostcomputer via at least one gateway.
 16. The network of claim 15, whereinat least one of the routers communicates with the host computer via atleast one other router.
 17. The network of claim 1, wherein at least onestar node has a sleep cycle that is controlled such that the at leastone star node wakes up for communication with a router at a time thatapproximately coincides with a period when the router is available forcommunication.
 18. The network of claim 1, wherein each router transmitsa beacon before at least one period during which the router is availablefor communication with at least one star node.
 19. The network of claim18, wherein the beacon includes one or more of a PHY header, a MACheader, a network identification number, a session identifier, a routeridentifier, a current time, a last time that network parameters changed,information for determining a dither, information for determining acurrently active communication channel and a list of children withstore-and-forward messages in a queue.
 20. The network of claim 1,wherein at least one router changes a length of a period during whichthe router is available for communication with at least one star nodebased on an amount of network traffic.
 21. The network of claim 1,wherein at least one router goes into a low-power sleep mode betweenmultiple periods during with the router is available for communicationwith at least one star node.
 22. The network of claim 1, wherein atleast one star node retransmits a signal on a second frequency uponfailure to receive a MAC-level acknowledgement after sending the signalon a first frequency.
 23. The network of claim 1, wherein a star noderesynchronizes its clock with that of a router by acknowledging a beaconsent by the router.
 24. The network of claim 1, wherein a star noderesynchronizes its clock with that of a router by listening for a beaconsent by the router around a scheduled time when the router is to sendthe beacon.
 25. The network of claim 1, wherein a star node or router isadapted to calibrate its clock based on detecting clock drift of itsclock in relation to another clock source.
 26. The network of claim 25,wherein a star node or router detects clock drift between two or moretime synchronization points with a parent node.